そのモノリス、本当にマイクロサービス化が必要？ サービスメッシュも？：AWSのエンジニアが問う

2020年2月13〜14日に開催された「Developers Summit 2020」のセッションに、アマゾンウェブサービスジャパンのHara Tori氏が登壇。サービスメッシュの必要性や、採用する際に考慮すべきポイントを解説した。

[齋藤公二，＠IT]

アマゾンウェブサービスジャパン シニアコンテナスペシャリスト ソリューションアーキテクト Hara Tori氏

　マイクロサービスの課題を解決する手段の一つとしてサービスメッシュが注目を集めている。だが、注目を集め過ぎるあまり、サービスメッシュを唯一の選択肢と考えてしまうきらいもある。そうした傾向に対し、「サービスメッシュが本当に必要なのかどうかについて、一度原点に立ち返って考えることが重要です」と説くのは、アマゾンウェブサービスジャパン シニアコンテナスペシャリスト ソリューションアーキテクト Hara Tori氏だ。

　「Developers Summit 2020」に「サービスメッシュは本当に必要なのか、何を解決するのか」と題して登壇したHara Tori氏は、講演の中で「サービスメッシュはなぜ必要なのか」「何を解決してくれるのか」について、1つのサービスが成長していく姿になぞらえながら解説していった。

そもそも「モノリス」って何だ？

　まず、何かのプロダクトやサービスを開発する場合、基本となるのは、フロントのロードバランサー（LB）、ユーザーからのリクエストを受けるアプリケーション（App）、その後ろにあるデータベース（DB）という構成だ。人気が出るとユーザーや機能が増え、アプリケーションも大きくなる。アプリケーションが大きくなると、デプロイに失敗してダウンタイムが発生するといったトラブルが発生しやすくなり、サービスに関するさまざまな課題が見えてくる。

「モノリス」と呼ばれるアプリケーション（サービスメッシュは本当に必要なのか、何を解決するのか / Service meshes - Do we really need them? What problems do they solve? - Speaker Deckから引用）

　「そこで課題を解決するためにマイクロサービス化しようという発想が出てきます。その瞬間からこれまで作ってきたサービスやプロダクトは『モノリス』と呼ばれるようになります。このモノリスという呼称に込められるニュアンスには、例えば『関係者間の調整にオーバーヘッドが生まれる』ことがあります。最初は2人で開発していたのに、マーケティングチームやセールスチームとリリース時期を相談したり、キャンペーンに合わせて機能開発を一時的に停止したりといった調整事が増えていきます。開発チームも増え、他のチームに依存する機能があったり、デプロイが遅れたりしていきます」

　モノリスに対しては、この他にも、「変更による影響範囲の広さ」「モジュール構造維持の難しさ」「非効率的なスケーリング」「テスト・ビルドに要する時間の長さ」などがある。

　例えば、非効率的なスケーリングとは、商品一覧とショッピングカートの機能が分離されていないため、ユーザーからのリクエストが増えたときに商品一覧機能だけではなく、サービス全体をスケールする必要があるといったケースだ。

　モノリスのこうした課題感を解決する方法の一つがマイクロサービス化だ。具体的には「変更による影響範囲の局所化」「モジュール境界の維持しやすさ」「独立したデプロイとスケーリング」「自律的なチームによる開発・運用」「Polyglot（-able）／多言語」などの効果を期待することになる。

「よくできたモノリスが最高」――分散トレーシングで対応できるケースも多い

　しかしここでHara Tori氏は、「アプリケーションが大きくなることで生まれる課題は果たしてマイクロサービス化によって解決できるのか？」という疑問を投げ掛ける。

　「商品一覧とショッピングカートを別のサービスとして実装することで、課題を解決できるかもしれません。しかし、私は『よくできたモノリスが最高』という持論を持っています。そこで、もう少しモノリスを見つめ直してみます」

　先ほどの「ロードバランサー、アプリ、データベース」という構成をAmazon Web Services（AWS）の具体的なサービスに置き換えると「ALB（Application Load Balancer）、Amazon Elastic Compute Cloud（EC2）／Container、Amazon Aurora」などとなる。可用性や耐障害性を考慮してEC2は3台稼働させ、その一部をAmazon S3やAmazon ElastiCache（Redis）などに格納したり、データベースをバッチ処理し、Amazon Simple Queue Service（SQS）で処理したりする。

現実世界のモノリスは複雑（サービスメッシュは本当に必要なのか、何を解決するのか / Service meshes - Do we really need them? What problems do they solve? - Speaker Deckから引用）

　「AWSを使っているとこうした構成はごく一般的なものです。現実世界のモノリスは、さまざまなサービスの複雑な組み合わせで構成されています。もしこのときにユーザーにリクエストを返すまでに2秒かかっていたとします。時間がかかっている通信を特定することは簡単ではなく、ALB〜App間、App〜S3間、App〜SQS間、App内処理など、さまざまなケースが考えられます。調べてみても原因にたどり着けないことも多い。ただ、こうした分散アプリケーションの分析と調査のためのサービスもあり、それを使うことで問題を追跡できます」

　AWSのサービスでいえば、「AWS X-Ray」が、そうだ。AWS X-Rayは、サービス間通信の可視化や、エラーの原因となるサービスやパフォーマンスのボトルネックの発見が可能な分散トレーシングサービスだ。

　このように、一口にモノリスと言っても、複数のサービスで構成され、分散トレーシングの仕組みが必要となるケースは多い。逆に言えば、必ずしもマイクロサービス化が必要なのではなく、X-Rayなどの仕組みで解決できるケースも多いということだ。

　「そもそも、マイクロサービスにする必然性はどれぐらいあるのでしょうか。コードの品質保証やテストの不足をモノリスのせいにしていないでしょうか。マイクロサービスにしても、これらが不要になるわけではありません」

　では、本当にマイクロサービスが必要になるのはどういったケースなのか。

　Hara Tori氏の個人的な考えによると、マイクロサービスを選択するのに妥当なのは「組織のスケーラビリティがプロダクトにマッチしなくなったとき」だという。組織を大きくしたいのに、プロダクトに何人投入してもプロジェクトが進まない。そのようなときに、組織のスケーラビリティを確保するためにマイクロサービスを選択するとのことだ。

マイクロサービス特有の課題とは

　では、マイクロサービスを検討するとなったときに、その課題と解決策についても把握しておかなければならないだろう。マイクロサービス特有の課題にはどのようなものがあるのだろうか。