「Cloud Native Trail Map」の10ステップを紐解く(ステップ4～5)

はじめに

国内外で「クラウドネイティブ」に取り組む企業やエンジニアが増え、クラウドネイティブ関連のイベントへの参加者も活況を呈しています。一方で「クラウドネイティブとは、なんでしょうか?」という疑問を持っている方々も多くいます。

そこで本連載では、クラウドネイティブについて解説するとともに、それを支える基本的なテクノロジーやソフトウェア、そして、特にエンジニア視点として、どのように学んでいくかを紹介していきます。

今回は前回に引き続き、クラウドネイティブを実現するための道しるべとなる「Cloud Native Trail Map」について、ステップ4～5までを解説します。

Cloud Native Trail Mapの
10のステップ

Cloud Native Trail Mapには全部で10ステップありますが、ステップ3以降はすべてオプションで、状況に応じて選択されています。従って、クラウドネイティブになるには10個すべてのステップを達成することではないことに注意してください。

ステップ4:観測性と分析

ステップ4では、何が起こっているのかを監視、ロギング、トレーシングします。そして、運用段階においては、結果を見た上で分析することも必要になります。

クラウドネイティブ・アプリケーションとは、コンテナをKubernetesのようなオーケストレーションツールを利用して構成し、マイクロサービスで疎結合されたアプリケーションとも言えます。コンテナ数は数百から数千といった単位で動作し、それらが組み合わさって動くため大量のリソース情報やログデータが生成されます。したがって、多くのデータやログを扱える監視ツール、ログ収集ツール、そしてトレーシングツールが必要となります。

Cloud Native Trail Mapでは、監視ツール「Prometheus」でモニタリングを行い、ログ収集ツール「Fluentd」でロギングを実施し、トレーシングツール「Jaeger」でトレーシングを実行することを紹介しています。

これらのツールは、CNCF(Cloud Native Computing Foundation)でGraduated(卒業)プロジェクトとなっています。CNCFでは機能面やコミュニティが十分に成熟すると、支援してきたオープンソースを卒業プロジェクトとします。そのため、現在は各ツールともそれぞれのコミュニティによって管理されています。

Prometheus

Prometheusは、もともとSoundCloud社により開発された監視ツールで、ネットワークやサーバー、サービスの状態などのリソース情報を収集・蓄積し、それらの閲覧や特定の条件を元に通知を行うことなどができます。

監視したいリソースの種類ごとに「exporter」と呼ばれるプログラムがリソース情報を取得し、Prometheusの監視サーバープログラムがexporterからリソース情報を収集します。exporterはサードパーティ製も含め、目的に応じてさまざまなものが開発されています。また、公式ドキュメント上にはexporterを作成するためのガイドラインなども用意されています。

●Prometheusの公式ドキュメント「EXPORTERS AND INTEGRATIONS」：
https://prometheus.io/docs/instrumenting/exporters/

Prometheusのアーキテクチャ

上図のアーキテクチャにあるように、データを可視化するためには「Grafana」などを利用できます。

●Prometheus公式サイト：https://prometheus.io/

Fluentd

Fluentdは、プロジェクトの主要スポンサーであるトレジャーデータ社の共同創業者、古橋貞之氏により考案されました。公式サイトによれば5,000社以上のデータ駆動型企業が利用しており、5万台以上のサーバーからデータを収集しているそうです。

Fluentdは、データコレクターやデータログ収集ツールと呼ばれるソフトウェアです。大量のログファイルを収集・解析し、ストレージに集約、保存(ログ形式は基本的にJSON)ができます。特徴として、ログの収集方法や保存場所を柔軟にカスタマイズできることがあります。プラガブル・アーキテクチャを持ち、500以上のプラグインがあります。

AmazonやMicrosoftといったクラウド大手に加えて、日本でもグリー、任天堂などで採用されていることが紹介されています。

Jaeger

Jaegerは、分散トレーシングソフトウェアです。

トレースツールとは、アプリケーションの変数情報やメソッドの呼び出し関係など、トレースを行うツールです。このような分散環境では、マイクロサービスが複雑に絡み合い、情報量が多いため、ソフトウェアの変数情報やメソッドの呼び出しなどをトレースすることは困難でした。そこで必要になったのが分散トレースです。分散トレースは多くの場合、サービスメッシュ(マイクロサービスを管理および監視する方法)の一部として実行されます。

このような分散トレースを実行するソフトウェアの1つがJaegerです。Jaegerを利用すると、分散トランザクション監視、パフォーマンス・遅延の最適化、根本原因分析、サービスの依存分析、分散コンテキスト伝搬を実行できます。

●Jaeger公式サイト：https://www.jaegertracing.io/

ステップ5:サービスプロキシ、ディスカバリー、メッシュ

ステップ5では、クラウドネイティブアプリケーションのヘルスチェック、ルーティング、ロードバランシングを行います。Cloud Native Trail Mapでは「CoreDNS」「Envoy」「Linkerd」を紹介しています。

CoreDNS

CNCFの卒業プロジェクトであるCoreDNSは、シンプルかつ軽量で高速、拡張性が高いDNSです。Kubernetesはオーケストレーション機能を実現するため、内部にDNS機能が必要です。Kubernetes 1.11からは、デフォルトのDNSとしてCoreDNSが選択可能となっています。

●CoreDNS公式サイト：https://coredns.io//

Envoy

疎結合されたクラウドネイティブ・アプリケーションが連携するために利用されるプロキシソフトウェアとして開発されたのがEnvoyです。

C++で開発された高性能分散プロキシシソフトウェアであるEnvoyは、NGINX、HAProxy、ハードウェアロードバランサー、クラウドロードバランサーなどのソリューションのナレッジを活用して開発されたそうです。

EnvoyはHTTP/2とgRPCをサポートし、ロードバランシング機能も持ちます。さらに、L7トラフィックを管理するため、HTTP L7フィルターレイヤー、MongoDBやDynamoDBなどのL7サポートも行います。

ライドシェアサービスLyftが開発を開始し、2017年9月にCNCFのIncubatingプロジェクトとなり、2018年11月にKubernetesとともにGraduatedプロジェクトとなりました。

Amazon、Microsoft、Googleといったクラウド大手に加え、日本ではYahoo! ジャパンが採用していることが紹介されています。

●Envoy公式サイト：https://www.envoyproxy.io

Linkerd

Buoyant社が開発をスタートしたLinkerdはCNCFのIncubatingプロジェクトで、Kubernetesのための軽量サービスメッシュです。コードに変更を加えることなく、ランタイムデバッグ、観察可能性、信頼性、セキュリティを提供することで、サービスをより簡単かつセキュアに実行します。

Linkerdのアーキテクチャは、大きく「コントロールプレイン」と「データプレーン」に分けられます。コントロールプレーンは専用のネームスペースで動作するサービスです。これらのサービスはテレメトリーデータの集約、ユーザー向けAPIの提供、データプレーンプロキシへの制御データの提供などを実行します。これらのサービスが一体となって、データプレーンを動作させます。

データプレーンは、各サービスインスタンスに隣接して実行される軽量なプロキシ群です。プロキシはサービスとの間のすべてのトラフィックを自動的に処理します。コントロールプレーンにテレメトリを送信したり、コントロールシグナルを受信したりします。

●Linkerd公式サイト：https://linkerd.io/

おわりに

ステップ4、5で紹介されているオープンソースは、以前から有名なソフトウェアもあれば、今ホットな領域のソフトウェアもあります。特に、サービスメッシュは一種のバズワードとも言える盛り上がりを見せています。クラウドネイティブの道を歩く途中で寄り道をして、色々と調べてみるのも良いかも知れません。

次回も引き続き、Cloud Native Trail Mapのステップ6から紹介していきます。