CDK Globalのデジタルマーケティング事業部は、次世代インフラストラクチャのコンテナ化アプローチに移行しました。
同社では、コンテナ内のJavaアプリケーションをどのように監視するか、という課題がありました。
本稿では、課題の詳細とSysdigの活用事例をご紹介します。
CDK Globalは、北米、ヨーロッパ、中東、アフリカ、アジア太平洋および南米に跨って、自動車、トラック、オートバイ、船舶、レクリエーション車両および重機の27,000以上のディーラーに対し、統合的な技術ソリューションを提供している企業です。
CDK Globalには、パートナー向けにデジタルマーケティング・ソリューションを提供している部門があります。
CDKのシニアエンジニアであるBranden Makana氏は次のように説明しています：
私たちは、エンドツーエンドの顧客体験の向上を可能にする技術をお客様に提供しています。
ウェブサイトからディーラーロットにいたる全てにおいて、『一貫した価値ある体験』というものをイメージしてみてください。
Branden氏は、CDKの前述の部門について詳しく説明しています。
CDKは、世界中の自動車ディーラーが必要とする技術を総合的に提供しています。
私の部門は、パーソナライズされた消費体験に特化しています。
本質的には、社内のデータ分析部門と考えていただければよいと思います。
また、テクノロジーに先進的な企業として、次世代のアプリケーション・インフラストラクチャのために、事業部全体で共通のプラットフォームを持ちたいと考えていました。
当社の提供するサービスやアプリケーションの多様性を考慮すると、これは非常にチャレンジングなことでした。
でも、この挑戦のスタート地点として、当社のデータ分析部門は最も適していました。
私たちは2つの環境と2つのデータセンターを持っていました。
以前はカスタムPaaSを利用していましたが、次世代型のテクノロジーにはマッチしませんでした。
そこで、CoreOSを使った新しいコンテナ・インフラストラクチャの検証を始めました。
Dockerについては後ほど触れるとして、まずは私たちのアプリケーションについてお話しましょう。
CDKのアプリケーションの多くはJavaベースでした。
Branden氏は次のように述べています。
データ処理とETLを目的として我々が構築したアプリケーションは、Javaを使用したWebアプリケーションです。
通常はREST APIで連携し、フロントエンドにはNginxを使用しています。
また、多くの PHP アプリケーションも提供しています。
Branden氏は、彼のチームについても詳しく説明しています。
我々の部門内には10チームの開発ユニットがあります。
私たちは皆、DevOpsモデルを採用しています。
つまり、各チームは、共有インフラストラクチャ内で、それぞれのモニタリングデータにアクセスする必要性があるということなのです。
このことは、どのようにシステムを監視するかを決定した理由に大きく影響しています。
Branden氏は次のように過去を振り返っています。
私たちの既存のモニタリング・インフラストラクチャは、エンドポイントのアラートにnagiosを使用していました。
Java MelodyはJMXのメトリクスを保持しており、Graphiteは10万以上の統計情報を保持しています。
Graphiteはオープンソースでしたが、作業負担を考えると決して安価とはいえませんでした。また、Graphiteのデータ保持期間はわずか2週間程度でした。
Branden氏は、Sysdigとの出会いを次のように振り返ります。
私はCoreOS FestでSysdigに出会い、Sysdigこそがコンテナを監視する有望な方法のように思えました。
Docker化されたインフラはかなり複雑で、その複雑さを実際に理解している監視システムの方が良いと考えました。
それがSysdigを試してみようと思った強力な理由なのです。
Sysdigは、単純にDockerコンテナを監視するだけでなく、Dockerコンテナの内部までも詳細に見える化できたのには、とても驚きました。
コンテナ内で稼働している全てのアプリケーションを効果的に見ることができたため、Sysdigは信じられないほど強力でした。
Branden氏は、メトリクスの組み込みについて次のように説明しています。
Sysdigはメトリクスを本当に簡単にしてくれました。
開発の観点から言えば、我々は何もする必要がなく、エージェントをドロップインして実行するだけです。
Sysdigのメトリクスの組み込みは、ホストのリソース、ネットワークの利用状況、コンテナ統計、アプリケーションのパフォーマンスなど、何百もの基本的なメトリクスをシステムコールから収集します。
更に付け加えるならば、Java Melodyのプロパティをプラグアップする必要がありません。
実現しうる最大限の『セルフサービス』と言えるでしょう。
引継ぎも、結合作業も必要ない。これは生産性の大幅アップになります。
Sysdigを起動してからは、探索ページに多くの時間を費やしていたことがわかりました...。
これは、問題を解決しようとしているときに、アプリケーションのメトリクスを様々な切り口から分析し理解することができる、直感的な方法です。
もう一つの本当に便利な機能は、グループ化です。
データセンターや、アプリケーション、サービスなどのカテゴリ別に整理するため、我々はDockerのラベルを使用しています。
Sysdigはこれらのメタデータをネイティブに理解しており、全てを収集してくれます。
つまり、いつでも表示を切り替えることができるのです。
データセンター全体のパフォーマンスを見たり、アプリごとのビューに切り替えたり、サービスを分離したりと、いつでも素早く切り替えることができます。
ダッシュボードの利用もどんどん増えています。
1つの画面にすべての主要なメトリクスを表示できるモニタリングアプリケーションは、ほとんどありません。
さらに言えば、膨大なデータ量にもかかわらず、Sysdigのパフォーマンスは非常に優れています。
驚くべきことに、なんとSysdigは無制限にデータを保持しています。
私たちが驚いたのは、SysdigでJavaアプリケーションの全貌を見ることができたことです。
今までで初めて、ホストからネットワーク、コンテナ、JVM、JMX、アプリケーションメトリクスまで、すべてを一元的に見ることができました。
コンテナ内で JMX メトリクスを収集するのは、特定の JMX ポートを開く必要があるため、困難な場合があります。
ほとんどの場合、これを可能にするためには開発者がコンテナイメージを微調整する必要があります。
つまり、開発者はDocker Hubから用意されたコンテナイメージを再利用することができず、使用しているクラスタ管理ソフトウェアにこの情報を伝播させなければなりません。
これは、グローバルポーリングやサイドカーコンテナの実行時にポートを公開することを意味し、追加のリソースと設定が必要になります。
SysdigはJMXメトリクスを見るだけです。
どこから書き出されたか、どこへ書き出されたかは関係なく、Sysdigはシステムコールでそれらを見て収集するだけです。
これは私たちの開発チームにとって大きな恩恵です。
これにより、メトリクスを扱うコードを修正したり、サイドカーコンテナをセットアップしたりする必要がなくなりました。
これはPaaSの次のバージョンでも、開発者が基礎となるインフラストラクチャにアクセスできない場合には非常に有効です。
Sysdigを使って多くの問題をトラブルシューティングしました。
例えば、コンテナがkillされた理由を見つけるのは簡単でした。
パフォーマンスの低下が見られたので、Dockerコンテナのメモリ・リークイベントと関連付けることができました。
もしあなたがJavaアプリやその他のコンテナを監視することを検討しているなら、次のBranden氏のアドバイスを参考にしてはどうでしょうか？
まず1つ目に、コンテナの中を見ることができるツールが必要です。
それには、開発チーム側の作業をほとんど必要とせずにそれを行えるのが重要です。
2つ目は、モニタリングツールの目的があなたの目的と合致していることです。
Branden氏は、その意味を説明してくれました。
我々はSysdigを使って、よりエンタープライズ的な視点を持つことを期待しています。
先に述べたように、私たちは次世代のPaaSを構築していますが、Sysdigはその中で重要な役割を果たします。
私が特に気に入っているのは、開発チームやサービスごとにデータを分離できる新機能『Teams』です。
これは、共有環境からさらに多くの開発チームが作業している場合に特に便利です。
Sysdig は我々が将来必要とする機能の種類を慎重に考えていて、我々の成長とともに変化しようとしているのは明らかです。
Sysdigが可能にしてくれたシンプルで直感的なトラブルシューティングを行うことで、多くの時間と労力を節約することができます。
つまり、私たちは、優れたコードの開発に集中できるということです。
