ITコラム

クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.3

2019年12月6日

カテゴリー ITコラム

記事をシェアする:

クラウド・ネイティブ基礎知識解説の連載3回目。クラウド・ネイティブの代表的なアプローチであるマイクロサービス、サービス・メッシュ、分散トレーシング、宣言型APIについて解説する。

執筆者：高良真穂 ID:maho.takara
日本IBM クラウド＆コグニティブ・ソフトウェア事業本部、「15Stepで習得 Dockerから入るKubernetes」の著者

OpenShift／Kubernetesの導入で成果をあげる道

クラウド・ネイティブ基礎知識解説

1. CNCFとは（Vol.1）
2. クラウド・ネイティブの定義（Vol.1）
3. クラウド・ネイティブの特徴的アプローチ（Vol.2）
3-1. コンテナ（Vol.2）
3-2. イミュータブル・インフラストラクチャー（Vol.2）
3-3. マイクロサービス
3-4. サービスメッシュ
3-5. 分散トレーシング
3-6. 宣言型API：declarative APIs
3-7. コンテナ・オーケストレーター Kubernetes（Vol.4）
3-8. モニタリングとロギング（Vol.4）
4. クラウド・ネイティブ推進の課題と解決の取り組み（Vol.4）
5. まとめ（Vol.4）

3-3. マイクロサービス

コンテナなどの技術を使用して、そして、イミュータブル・インフラストラクチャーの概念を取り入れたアプリケーションに、残る課題は、スケーラビリティ、可用性、そして、リリースまでの期間短縮である。特にスマートフォンやタブレットが、アプリケーションのクライアント・ターミナルとして普及することで、次の段階の対策が必要となっている。

これら前述に挙げた課題に対するソリューションとして注目されるのが、マイクロサービスである。

モノリスとマイクロサービスの概念図

マイクロサービスは、マイクロサービス・アーキテクチャーとも呼ばれ、アプリケーションを構築するためのアーキテクチャ上のアプローチである。アプリケーションは、一つの実行単位で動作するのではなく、小さな機能ごとに分割され、それぞれが独立したサービスとして動作するために、マイクロサービスと呼ばれる。

独立した小さな単位のサービスは、以下の特性を有する。

保守とテストが簡単
サービスどうしが疎結合
独立してデプロイ可能
ビジネス機能を中心に編成
小さなアプリケーションチームが所有

これらの特性により、開発サイクルを短くすることができ、より早くビジネスの要求に対応できる。また、小さな機能単位に分割して、独立して稼働するため、デベロッパーが把握するべき範囲が少なくなるので、学習期間が短くなり、デベロッパーの早期の戦力化が可能となる。

非機能要件の観点からは、一つのマイクロサービスに問題があっても、全体へ与える影響が限定的になり、可用性が向上する。同一のマイクロサービスの数を増やして並列度を高くすることで、処理性能をスケールできる。

このマイクロサービスには利点も多いが、下記に挙げるような欠点も特徴である。これは一つのモノリスから、細分化することに由来する欠点である。

同一モジュール内でメソッド等をコールから、独立したサービスへのアクセスに変わるため、複雑化する
小さくても独立した単位のアプリケーションとなるため、データベースやHTTPサーバーなどの重複が増え、効率は下がる

マイクロサービスには利点も多いが、欠点も大きいので、アプリケーションは、最初からマイクロサービス・アーキテクチャーで作るべきではない、とする議論もある。最初はモノリスから始めてモジュール化し、モノリスが問題になったらマイクロサービスに分割するのが良いとされる。

参考資料

3-4. サービスメッシュ

マイクロサービスの導入を決めた際に、運用に立ちはだかる最大の課題は、複雑化への対処である。

例えば、Kubernetesの基本機能(サービス)だけを使用したマイクロサービス間の連携では、マイクロサービス相互の依存関係や通信状態、特定のマイクロサービスの処理時間といった、システム内部の活動状況が把握できない。このような管理レベルで、本番サービスに適用した場合、マイクロサービスの一部にスローダウンが発生すると、問題箇所を特定し、部分的にスケールするなどの対処の判断が難しくなる。

この課題に取り組むのが、サービス・メッシュである。つまり、サービス・メッシュはマイクロサービスを運用する上で重要なインフラストラクチャ・レイヤーである。

サービス・メッシュとは、ネットワーク上のサービスを抽象化して、マイクロサービス間に、信頼性と高速な通信を提供することを基本に、可観測化、アプリケーションの識別、ロードバランシング、認証、暗号化が含まれる。

サービス・メッシュの役割

サービス・メッシュの仕組みを簡単に説明する。ネットワークを流れるリクエストは、サービス・メッシュが提供するプロキシによって、マイクロサービスへの経路が決められる。このプロキシの存在によって、サービス・メッシュを利用するためのコードを各マイクロサービス内部のコードに組み込む必要は無い。このプロキシは、KubernetesのPodオブジェクトのサイドカーと呼ばれる機能を利用して、コード変更不要の利便性を提供する。

さらに、代表的なサービス・メッシュの中央コントローラーは、サービス・メッシュ内部の接続の調整と協調機能を担う。具体的にコントローラーは、アクセス制御、ネットワークと性能の管理、そして、Kubernetesのようなコンテナ実行環境と統合である。

サービス・メッシュのOSSプロジェクトには、以下がある。

様々なサービス・メッシュが乱立する状態で、共通標準の定義を目指すService Mesh Interface（SMI）がある。Kubernetesで実行されるサービス・メッシュの仕様であり、さまざまなプロバイダーが実装できる共通の標準を定義する。

3-5. 分散トレーシング

サービス・メッシュと合わせて利用されるのが、分散トレーシングである。これは、マイクロサービスで構築したアプリケーションのプロファイルと監視に使用される。特に障害が発生した箇所とパフォーマンスの低下の原因を特定するために用いられる。

マイクロサービスでは、リクエストに応答を返すまでに、さらに複数のマイクロサービスを呼び出す。そのため、コードをトレースしただけでは、アプリケーションの動作を理解し、問題をトラブルシューティングすることができない。このような課題に対処するためのツールでCNCFのプロジェクトを以下にリストする。

参考資料

3-6. 宣言型API：declarative APIs

クラウド・ネイティブのソフトウェアのAPIは、宣言型APIを採用している。この方式を採用することで、自律的な動作や制御が期待できるため、アプリケーションのサービス運用の複雑さが軽減され、シンプルになる。そして、AI技術を活用した高度な自律的な自動運用への期待もできる。

宣言型APIとは、次の挙げる手続き型プログラミング言語やオブジェクト指向型プログラミング言語からコールすることができて、目的とする状態をAPIで対象に指示する。

宣言型APIの概念図

APIで目的とする状態の指示を受けたソフトウェアは、その状態を維持するように、自律的に動作する。例えば、アプリケーションのインスタンスを3つ起動した状態を指示した場合、そのインスタンスの一つが何かの障害で停止すると、代替のインスタンスを起動して、インスタンス数 3 を維持するように振る舞う。

KubernetesのAPIでは、URLを指定してHTTPSプロトコルでRESTサービスをアクセスして利用する。さらに、プログラミング言語から利用しやすいように、Python、Go、Javaなどのライブラリが提供される。宣言型APIとして設計された KubernetesのAPIは、手続き型プログラミング言語のように実行すべき命令を順に記述して操作するAPIではなく、Kubernetesのオブジェクトの望まれる状態を、JSONやYAML形式で与えるAPIである。