Kubernetes、マイクロサービスのスピーディな開発にHashiCorp Consulが必要な理由

企業の情報システムが従来のオンプレミス型からクラウドへと進み、さらに仮想化の一形態であるコンテナを活用したものへと変化しています。それに従って、コンテナ向けアプリケーションを構築する手法として、「マイクロサービス」に注目が集まっています。

マイクロサービスとは「アプリケーションを単一の機能を行う小さな単位（サービス）に分割し、それぞれを独立して開発、デプロイする」考え方です。目指すところは、アプリケーションをよりスピーディに開発し、運用していくことにあります。

消費者向けのECサイトなどでは、利用者に飽きられないために日々コンテンツを更新し、新しいサービスを立ち上げていく必要があります。サイトによっては1日に数回更新することもあり、従来型のアプリケーション開発手法ではそのスピードについていけない可能性があります。

今回はアプリケーションのコンテナ化とそれを実現するマイクロサービスについて、さらにはマイクロサービスのメリットを最大限に生かすために複雑なインフラ調整を自動化する「HashiCorp Consul」の利用により、スピーディに開発、運用する仕組みを紹介します。

マイクロサービスとは

マイクロサービスは、各サービスが独立して起動し、相互に通信することで、ユーザにアプリケーションとしての機能を提供します。ここでは一例として買い物機能を紹介します。

図1のように、マイクロサービスのシステムでは、「商品検索」「決済」「レコメンド」「ユーザ管理」など個々のサービスが独立しています。他サービスとの連携（通信）はAPIを通じて行われます。このため、あるサービスを改修しても、APIの仕様に変更がなければ改修の影響が他サービスに及びません。このように、サービス同士が疎結合の関係にある点が、マイクロサービスの特徴です。これにより各サービス担当者は独立して、スピーディに作業を進めることが可能です。

一方で、従来型の「モノリシック型アプリケーション」についても、確認しておきましょう。ある買い物アプリが存在した場合に、そのアプリケーションには図2のように、買い物を実現するために必要な「商品検索」や「決済」といったサービスが組み込まれています。モノリシック型アプリケーションでは、商品検索、決済、レコメンド、ユーザ管理といったサービスが、すべて統合されたアプリケーションとして起動します。

このようなモノリシック型アプリケーションにおいて、OSやミドルウェアのバージョンアップが必要になった場合、事前に全てのサービスについて影響を調査する必要があります。

また各サービスは密に連携している（密結合）ため、例えば商品検索サービスに改修を加えた場合の影響は、他サービスに及ぶ可能性があります。そのため改修時の影響範囲は広く、各サービスを担当しているチーム間の連携や試験も必要になり、この調整のために多大なワークロードが発生してしまいます。

マイクロサービスの課題

マイクロサービスは、従来のモノリシック型アプリケーションに対して、疎結合である点などの優位性を持つことが分かりました。ただし、マイクロサービスには課題もあります。マイクロサービス化されたアプリケーション内では、個々のサービス間の連携時にAPIを経由するため、ネットワーク間通信の考慮が必要になります。通信する相手サービスのIPアドレスを知ることはもちろん、通信におけるセキュリティや、サービス単位での死活監視も必要です。

特に最近はマイクロサービスをコンテナ化し、コンテナ化したアプリケーションを管理するオーケストレーションツール「Kubernetes」を利用して、運用を自動化する取り組みが広く実施されています。

Kubernetesを使用すれば、複数台のプラットフォームで構成される実行環境を「クラスター」という単位で結合し、1台の実行環境のように扱えます。これにより、プラットフォームのリソースを超えた、コンテナのスケールアウトが可能となります。さらにスケジューリング機能を使用すれば、コンテナの配置という課題をKubernetesが自動で解決してくれます。

この際、コンテナ化されたマイクロサービスがプラットフォーム上のどこに配置されるかにより、IPアドレスが動的に変わります。そしてそれをタイムリーに把握できなければサービス同士が通信できません。

マイクロサービス化により開発がスピードアップし、さらにKubernetesの利用によりコンテナ化と運用自動化を進めているのであれば、動的に割り当てられるIPアドレスの解決と、セキュアな通信設定を自動化しなければ、それがスピーディな開発運用を妨げる要因となってしまいます。

スピーディな開発運用への解決策

HashiCorp社が提供するHashiCorp Consulは「サービスディスカバリ」「サービスメッシュ」により上記の問題を解決します。この2つの機能を組み合わせることにより、ネットワーク設定の自動化（ネットワークオートメーション）が実現します。図4、5、6を参照しながら、サービスディスカバリ、サービスメッシュについて詳しく解説します。

（1）サービスディスカバリ

サービスディスカバリとは、日本語では「サービスの発見」「検出」という意味になりますが、ここではプラットフォーム上で動作しているサービスについて、ポート番号、IPアドレス、ホスト名などをリアルタイムで知る方法を指します。

従来のサービスディスカバリ機能はDNS（Domain Name System）が提供していました。DNSはホスト名とIPアドレスの組み合わせを固定で記述しており、デプロイやリリースにより新しいIPアドレスが割り当てられる度に手動で設定変更を行うか、事前に各クラウドプロバイダーが提供するロードバランサーとの連携設定を行う必要があります。

ですがスケーラブルな環境では、IPアドレスは動的に変化する上に、ネットワーク上でそのサービスを見つけ出す機能も必要になり、かつシンプルなアーキテクチャで実装することが望まれます。

HashiCorp Consulはこのようなスケーラブルな環境でのサービスディスカバリ機能を提供します。

Consulノードが常にサービスを監視し、スケールなどにより状況に変化が発生するとConsulサーバにデータを送信します。Consulサーバはその受け取ったデータをサービスカタログに保管します。そして通信を行いたい各サービスはConsulに対しREST API、DNS、コマンドラインという3つのインターフェースを通して問い合わせすることにより、通信したい相手のホスト名、IPアドレスをリアルタイムに知ることができます。

（2）サービスメッシュ

サービスディスカバリによりマイクロサービス同士がスピーディに、自動で連携できるようになりました。ですがマイクロサービス同士の連携はさらにセキュリティ確保、連携する他サービスによる障害時の対応などを考慮しなくてはなりません。

これらを実装するにはサービス同士で認証・認可を行う必要がありますが、この仕組みをサービスごとで個別に実装するとなると、開発者に負担がかかります。この課題をConsulのサービスメッシュが解決します。

具体的には下の図6にあるとおり、各サービスに対して「サイドカープロキシ」を用意します。サイドカープロキシは認証・認可、そしてセキュアな通信、自サービスの死活監視機能などを有しています。そしてサービス間の通信はすべてこのサイドカープロキシ経由とすることにより、前述のマイクロサービス固有の課題を解決し、アプリケーション開発者がビジネスロジックの開発に専念できます。

Consulのサービスメッシュが提供する機能は以下のとおりです。

Service Access Graph	L4レイヤーのアクセスコントロール（ACL）設定をサービス名ベースで実現
Service Segmentation	mTLSや証明書発行等の機能を包括的に提供
Layer 7 Observability	L7のメトリクスやトレーシング、監査ログ等を取得、転送
Layer 7 Traffic Management	HTTPのパス、パラメータやヘッダーなどを使って重み付けルーティングなど高度なトラフィック制御を実現
Mesh Gateway	透過的にデータセンター間のトラフィックをサービスベースでルーティング
Centralized Configuration	サービスのコンフィグレーションを中央集権的に管理し各サービスへ配布

さいごに

最近では企業システムのマルチクラウド化が進み、サービスをクラウドごとに分けて運用している事例も多く見られます。こういった異なるクラウド上で動作するサービスを連携する場合にも、HashiCorp Consulは非常に有効です。

これまでラックが紹介してきたHashiCorp Terraformにより、マルチクラウド環境におけるインフラ構築を自動化し、さらに今回紹介したHashiCorp Consulによりマルチクラウド環境でのサービス間連携を自動化します。そして、サービス間連携の際に必ず使用する認証・認可情報（シークレット）をHashiCorp Vaultがセキュアに管理、自動化し、マルチクラウド環境における安全、効率的な運用自動化を一気通貫で実現できます。ぜひ、みなさんも試してみてください。