AWSでマイクロサービスを実現するサービスを調べてみた

マイクロサービスアーキテクチャを実現するためには、コンテナの実行環境以外に何が必要なのだろうか。特に、AWS上でそれを実現しようとすると、App Mesh やCloud Map、そしてX-Ray というものが出てくるようだ。

筆者がこれらを学ぼうと思い調べていた中で困ったのは、これらのツールの横断的な側面での目的や位置付けが、今ひとつ掴みづらいことだった。それだけでなく、個々の詳細は公式のドキュメントや解説記事などが見つかるのだが、特にApp Mesh は色々な機能を含んでいるためか、端的にそれを語る物が見つからない。言い換えると、「つまり何なんだ？」という疑問が中々消えない。初学者、0 を1 にしようとしている人間にとっては、これが中々に辛い。

そこで、本記事では筆者が調査した結果ややってみてわかったことに基づき、「マイクロサービスアーキテクチャを実現していく上でどういうものなのか」という観点にフォーカスし、それらの機能がどういう問題にどのように対応するものであるのか、という観点で整理した。

本記事では、それらの機能の「詳細」には踏み込まず、言ってしまえば「イメージ図」程度の内容になる。一体、何を元にそんな理解に至った（至れた）のか、という点を補足するため、筆者が活用させていただいたWebサイトのリンクなども記事下部に記載している。良ければ参考にしていただきたい。

App Mesh、Cloud Map、X-Ray とは何のためのサービスか

App Mesh 、Cloud Map 、X-Ray は、いずれも「マイクロサービスアーキテクチャ」において生じる問題を解決するためのものである。

ここでは、マイクロサービスアーキテクチャとはなにか、という点には深く立ち入らず、ざっくりと「細分化され独立して稼働する小さな【サービス】たちが、協調して動作することでシステムとしての目的を果たす、そんな構造」程度で捉えて貰えれば問題ない。

マイクロサービスアーキテクチャのメリットやデメリットは、現在では広く知られている。例えば、メリットの一つは「サービスの細やかなアップデートが可能であること」が挙げられる。イメージの上では、これは非常に想像しやすい。機能が細かく分割され独立性が高くなっていれば、きっとそれは容易だろう。逆に、全体を一括してデプロイしなければいけないシステムでは、とてもではないが数日単位のアップデートなどできないのは自然に理解できる。（あるいは実体験として痛感している人も多いかもしれない。）

一方、その難しさもまたいろいろにある。よく指摘されるのは「そもそも、どうやって/どのような基準で、機能を分割するのか」であったり、「それを維持するためには、システムだけじゃなくて開発者チームの形そのものを変えなければいけない」など多種多様だ。

ただ、こういった本質的な難しさ以前に、もっとシンプルな、システム面での実現性にかかる「難しさ」も存在している。例えば、アップデートが容易だ、という話も、少し想像してみると「実際、どうやるんだ？」という疑問にすぐ至る。コンテナを取り替えるのだろうか。でもその場合ダウンタイムはどうなる？新しいバージョンがコケたら切り戻さないといけない。どうやって？App Mesh 、Cloud Map 、X-Ray は、こういった問題を解決してくれる（ように導いてくれる）ものだ。

マイクロサービスアーキテクチャで生じる問題と、それぞれのサービスが実現する解決の仕組みを大雑把に整理すると以下の表のようになる。

次のセクションで、特にその「AWSサービス」の働きに着眼しながら、その問題と解決の仕組みについて解説していく。

App Mesh 、Cloud Map 、X-Ray の動作イメージ

ここでは、ECS を使ってコンテナを稼働させている、という状況を想定する。また、示す図は非常に模式的なものであるということをご了承いただきたい。

Cloud Map

Cloud Map は「DNSサーバのレコードの情報を、自動的に更新してくれる機能」である。

簡単な例を示す。ECS でサービスを作成する際に、Cloud Map を使用するように設定すると、起動後はこのような状態になる。

各ECSサービスにはコンテナが含まれており、このコンテナがIPアドレスを持つ。ECSサービスを作成する際に指定した名前にもとづき、各コンテナの「名前とIPアドレスの対応情報」、つまりDNSのレコードが自動的にRoute53 に登録される。

ここで、サービスBのコンテナが（オートスケーリングなどにより）増えたとする。すると、Cloud Map がそれを検知し、増えたコンテナのIPアドレスを登録する。（図では別々のAレコードを入れている形だが、これは表現上の都合で、実際は同じAレコードのIPアドレスが複数になる。）

この挙動はコンテナが減った場合も同じで、例えばコンテナB1 がいなくなれば自動的に “10.2.1.8” の情報が削除される。このように自動的にDNSの情報が変更されていくため、例えばサービスAがサービスBに接続しようとする場合は、単にDNSに “serviceb.demo.local” という名前で問い合わせれば良い。今存在しているレコードが適切に得られるし、すでに存在しなくなったコンテナのIPアドレスを使ってしまうということもない。

App Mesh

App Mesh は、各サービス間の通信を細やかに制御するためのものである。

今、あるサービスAを稼働しており、これが別のサービスBに対して通信しているものとする。ここで、サービスBの新しいバージョンが完成したのでとりあえずこれをデプロイしてみた、という状態が下の図である。（無論、現実でそんな無計画なデプロイをするわけがなく、簡便な説明のための都合である。）

ここで想定する「やりたいこと」はこうだ：

• サービスB とサービスBv2 の両方を残し、同時に使用したい
• 具体的には、サービスAからサービスBへ向かって行われていた通信の10% をサービスBv2 に流したい
• 一方で、その通信の都合のために、サービスA（のコンテナ設定やアプリケーションコードなど）に変更は加えたくない

このような目的が生じるのは、マイクロサービスアーキテクチャのメリットを安全に、十分に享受しようとした場合だ。そして、こういう場合にApp Mesh は活用できる。

（有識者にちょっと怒られそうなぐらい）簡便に記載したつもりだが、それでも複雑になってしまうため、少し説明を加える。

まず、App Mesh を使う場合新しい要素が2つ登場する。1つは、図の上部にあるApp Mesh という部分。もう一つは、ECSの枠組みの中の「プロキシ用コンテナ」という部分だ。App Mesh というのは、前者の仮想的な情報（これを「仮想的なルーティング設定」とここでは呼ぶ）を元に、具体的に通信を操作する後者のコンテナが協調して動作することで実現されている。

前者の「仮想的なルーティング設定」がApp Mesh の本質だ。（ちなみに、これは筆者の便宜的な呼称である。）ここでは仔細を述べることはしないが、具体的には “Virtual Service” や “Virtual Node” 、あるいは “Virtual Router” といったリソースを指している。この仮想的なルーティング設定は、作るのが大変だ。普段、NWの設定や問題などで頭を抱えたことがあれば想像しやすいだろう。この仮想的なルーティング設定を直感的に、構造的に定義できること。これが、App Mesh の目的であり本質である。

前者が本質的な「情報」であるなら、後者の「プロキシ用のコンテナ」は具体的な動作の仕組みに相当する。App Mesh に設定された「仮想的なルーティング設定」は、プロキシ用コンテナの「設定情報」の形でばらまかれる。そして、各アプリケーションコンテナの通信を常に媒介することで、すべての通信を把握し、操作し、またログやメトリクスの情報も得ている。このプロキシ用のコンテナは、響きは悪いが、例えるならあらゆる通信を検閲する憲兵がいる、と想像することもできる。（その場合、App Mesh は憲兵への指示を組み立てて指示書を配布し、報告を受け取る指揮所に当たるだろう。）

こんな面倒なことをして「ルーティング」する目的は、上で示した「やりたいこと」が、プリミティブな通信設備・機能では実現が面倒だからだ。そして、面倒ということは柔軟に対応しづらい上に間違えやすいということだ。上の例で言えば、最初は9:1 の割合で通信を振り分けて動作を確認し、翌日には 7:3 で少し負荷を増やし、更に翌日に割合を変えて、というように素早く柔軟に変えていきたい、というのは自然な話だ。これを直感的に定義でき、その直感的な定義を素早く間違いなく動作に落とし込む。これがApp Mesh であればできる。

X-Ray

X-Ray は、マイクロサービスアーキテクチャで構成されたシステムを可視化し、俯瞰・監視することができるようになるサービスだ。その動作は、App Mesh などと比べると直感的でわかりやすい。一言で言えば、各アプリケーションから「通信」のたびにログを送ってもらい、それを図に起こして見せてくれる、というものだ。例えば、以下のようにアプリケーションたちが動作しているとする。

X-Ray は、各アプリケーション（図でいうとコンテナA1 やコンテナB2 と言ったものたち）が、通信をするたびにログ（X-Ray ではこれをセグメントと呼ぶ）を受け取り、そこからシステム全体を「図」に起こして提示してくれる。その図のイメージは以下の様なものだ。

例えば、この図の場合、パッと見ただけで「コンテナA2からコンテナB1 の通信で成功率が低い理由はなんだろう？」といったことや、「コンテナC2 が表示されていないってことはログが来ていない。明らかになにかおかしい」といった示唆を得ることができる。また、この図では示していないが、図と一緒に、時系列でのメトリクスのグラフ（レイテンシの変化など）も提示されるため、「少し前から急に悪化しているな」といった見当をつけることも容易にできる。

情報量としてはログを直接見るよりむしろ減っている。それでもこういった可視化が重要なのは、「見ればわかるような問題が、実際に見てわかること」だ。テキスト状態のログをどれだけ集計しても「コンテナC2が全く活動していないぞ？」という事実を掴むのはとても労力がかかる。もしかして、と気付くのにも時間がかかるだろうし、実際にログがない、ということを立証することも大変だ。

最後に

今回、非常に簡素ではあるが、App Mesh 、Cloud Map 、X-Ray について整理して説明をしてみた。筆者は、これらを調査した結果、これらのサービスは「マイクロサービスアーキテクチャを実践する上で役に立つ」というよりも、「実践する上で必須である」と感じるようになった。これらの機能を欠いていると、場合によってはマイクロサービスのメリットを享受できないので、ただただ無意味に大変になってしまった、ということにもなり得ることを認識した。

勿論、マイクロサービスアーキテクチャを実践する上では、機能の分割の仕方や、それを維持していくための組織体制など、もっと本質的に難しい観点も多数あり、これらの課題を解決していかないとなし得ないことである。だからこそ、こういった機能を「基本的なもの」として理解し、いつでも選択し使用できるようにして置かなければ、スタート地点に立つことすらできないのかもしれない。

今回は、まだまだ仕組みが曖昧な部分もある中、自分なりに理解できた範疇を説明してみた。今後、更に理解を進めるとともに、もう少し実際的なところに踏み込んで、さらに全体の繋がりが分かりやすい解説をすることができればと考えている

付録1：参考となるサイト

• Cloud Map
  • DevelopersIO “サービスディスカバリハンズオン！手を動かしてCloud Mapを理解する！！”
  • https://dev.classmethod.jp/articles/cloudmap-handson-with-fargate/
  • タイトル通りで、Cloud Map をECS 上で使用して理解する、という内容のもの
  • 恐らく一番需要のあるだろう用途での利用ケースであり、実際に手を動かすことでその意味合いや位置付けが理解しやすい
• App Mesh
  • AWSドキュメント “Getting started with AWS App Mesh and Amazon ECS”
  • https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html
  • AWSの公式ドキュメントで、殆どハンズオンになっているため実践して理解を深めやすい
  • App Mesh はできることが多いため、対象範囲は狭くても実際にやってみた方が「あぁなるほど」と腑に落ちやすい
  • 前提として、App Mesh で作成するリソース（Virtual Service など）を把握しておくことや、ECSを使えることなどが求められる
• X-Ray
  • GitHub “AWS App Mesh Examples”
  • https://github.com/aws/aws-app-mesh-examples
  • GitHub 上に「App Mesh の具体例」という形で公開されている
  • 実行環境はCloudFormation のyaml 定義として、アプリケーションはGo 言語で記述されたものが、それぞれ同梱されているため、そのまま実行するのにも使えるし実際の用途の参考としても活用しやすい
  • 特に、X-Ray はドキュメントや参考文献が中々見つからない上に、設定しなければいけないインフラ環境も前提が長く、さらにアプリケーションコード上でも作業が必要になる。そのため、「これで正しく動くのか？」という疑念を持ちながら延々と作業し、やっぱり動かない、となるのが辛い。その意味で、この「正解」は非常に参考になった

付録2：「サービスメッシュ」という言葉との関連性

App Mesh やCloud Map 、X-Ray といった機能は、一般には「サービスメッシュ」と呼ばれる機能で括られている。非常に乱暴な表現になるが、サービスメッシュというのは、ここまでに述べてきたような「マイクロサービスで出てくる色んな問題への対処ツールの詰め合わせ」と言える。その意味で言えば、本記事は「サービスメッシュの持つ便利機能の幾つかをピックアップして説明したもの」だ。

サービスメッシュという考え方やツールは、コンテナオーケストレーションツールのデファクトスタンダードとも言えるKubernetes の世界で発展してきている。そのため、もし「他にどういう問題があって、それをどう解決しているのだろう？」と興味を持たれた場合、Kubernetes で多く使用されるIstio というツールを調べるのが良い。（ただ、繰り返しになるが、非常に広範な内容に渡る説明が返ってくることも多いため、当初は些か混乱する可能性もある。）

ちなみに、App Mesh で使用している「プロキシ用コンテナ」は、このIstio というツールで使用するものと同じEnvoy と呼ばれるものである。もしこのプロキシ用コンテナにも興味を持たれた場合は、これもIstio の観点で調べてみるとわかりやすいだろう。（AWS の文脈に絞ってしまうと逆に情報が出てきづらい可能性がある。）

おわりに

この記事はInsurtechラボ20233月アドベントカレンダー企画で記載しています。