検索
特集

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

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

Share
Tweet
LINE
Hatena

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

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

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

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

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

　「そこで課題を解決するためにマイクロサービス化しようという発想が出てきます。その瞬間からこれまで作ってきたサービスやプロダクトは『モノリス』と呼ばれるようになります。このモノリスという呼称に込められるニュアンスには、例えば『関係者間の調整にオーバーヘッドが生まれる』ことがあります。最初は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）で処理したりする。

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

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

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

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

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

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

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

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

　まず「サービスの適切な分割」がある。「サービスをどう分割するか」には、さまざまな方法論があるが、あくまで方法論にすぎず「これが正解」というのはないという。

　また「テストの難しさ」も大きな課題だ。「周りとの依存度をどうそろえるか」「チーム間をどう調整するか」は、モノリスのときよりも難しいものとなる。

　「影響範囲をサービス内に収める難しさ」もある。自律的にサービスを管理できるといっても好き勝手に開発運用していいわけではない。外部にAPIを公開する場合、APIの後方互換性を壊したり、勝手にダウンタイムを設定したりすることもできない。

　「課題の中でも特に注目しておきたいのが『サービス間通信の信頼性（Reliability）』『サービス間通信の可観測性（Observability）』です。マイクロサービスは分散システムの一種で、それぞれがネットワークで通信します。モノリスの場合、基本的に関数を呼び出せば、メモリが壊れていない限り成功していました。ところがマイクロサービスはネットワーク通信ですから、失敗することを考慮した実装が必要になります。また、マイクロサービスは複数のサービスで構成される1つのシステムです。失敗がシステムのどこでなぜ起きたか、システム全体を観測するための実装が必要になります」

　1つ目の信頼性を確保するための防御的な実装には5つのパターンがある。呼び出し先サービスの位置が一定ではないことに備えるための「サービスディスカバリ」、一時的な呼び出しの失敗に備えるための「リトライ」、継続した呼び出しの失敗に備えるための「サーキットブレーカー」、呼び出し先サービスのパフォーマンス悪化に備えるための「タイムアウト」、呼び出し元システムの不具合に備えるための「スロットリング」だ。

　また、2つ目の可観測性を確保する上では、ログ、メトリクス、トレース情報出力の実装が必要になる。

共通ライブラリの課題と、それを解決するプロキシの役割

　もっとも、マイクロサービスでこうした実装を行う上では、「各サービスにどう個別に実装していくか」「複数の言語やフレームワークの混在にどう対応するか」「実装担当者と品質保証方法をどうするか」などが課題になる。それらに対応するためには、チームの事情やスキルレベルの違いといった組織面の課題に左右されない一貫性のある方法が必要になる。

　「一貫性のある方法としてまず採用されるのが共通ライブラリです。セントラルチームが利用している共通ライブラリに、サービスディスカバリ、リトライ、サーキットブレーカー、タイムアウト、スロットリングを実装すれば、各チームの実装に関係なく、システム全体として統一されたログ、メトリクス、トレース情報が取れるようになります」

　一方で、共通ライブラリにも課題はある。しばしば声として上がるのは「アプリケーションの改修が必要だが、したくない」「共通ライブラリのせいでパフォーマンスが悪化した」「最新ライブラリに移行してくれない」「共通ライブラリのせいでバージョンが上げられない」などだ。つまり、共通ライブラリによって一貫した実装を実現しようとすると、せっかく疎結合にしたものが、また密結合を生んでしまうケースが出てくるということだ。

　「そこでアイデアとして生まれるのがプロキシです。プロキシを間において、全てのサービス間の通信を行う。この仕組みがサービスメッシュです。サービスメッシュでは、プロキシに欲しいものを全部入れます。サービスディスカバリ、リトライ、サーキットブレーカー、タイムアウト、スロットリングを入れ、さらにログやメトリクス、トレースをプロキシに担わせます。サービス間通信の信頼性と可観測性の両方をプロキシにオフロードすることで、アプリケーションの開発チームはプロキシを通して通信をするだけでよくなり、マイクロサービス都合の実装を行わなくてもよくなるのです」

　サービスメッシュを作るプロキシのデファクトとなっているのがオープンソースソフトウェア（OSS）プロジェクトの「Envoy」だ。YAMLファイルに設定を書くだけで、マイクロサービスで必要になる要件を実装できる。

プロキシを活用したにもかかわらず、せっかくの疎結合が密結合を生むケースも

　ただ、プロキシを活用したにもかかわらず、せっかくの疎結合が密結合を生むケースが出てくるという。

　「ビジネスロジック（アプリケーション）としての関心事と、マイクロサービス（システムアーキテクチャ）としての関心事は本質的に異なります。オペレーションのモデルもライフサイクルも異なります。せっかくこれらをマイクロサービスとして分離したのに、プロキシ設定に設定ファイルを利用することで、再び密結合になる可能性が出てくるのです、またプロキシの設定を変更する際には、デプロイと再起動が必要です。例えば、運用チームがログの仕組みを変えてデプロイしようとすると、アプリケーションとプロキシをセットでもう一度デプロイしなければならない。ライフサイクルの観点でプロキシとアプリケーションが再び密結合になるという課題が見えてきます」

　こうした課題に対応する方法の一つとしてAWSが提供しているのが「AWS App Mesh」だ。App Meshは、サービスメッシュのコントロールプレーンとなるプロダクトだ。メッシュ全体のトポロジーやメッシュ間の通信を定義しておくと、App MeshがEnvoyに設定を配信し、クラスタやサービスにまたがった動的なサービスメッシュを構築できる。サービスディスカバリ、リトライ、サーキットブレーカーなどのトラフィック管理や、ログ、メトリクス、トレース情報の出力も可能だという。

　Hara Tori氏は「App Meshのような動的なサービスメッシュではなく、静的設定ファイルを利用し、Envoyを高機能プロキシとして利用するので十分な場合もあります」と補足していた。

サービスメッシュが解決しないマイクロサービスの課題も

　Hara Tori氏は講演でマイクロサービス化を慎重に検討することの重要性について訴えていたが、サービスメッシュについても同様だ。

　「自社のシステムにサービスメッシュが必要かどうかをよく考えることが重要です。X-Rayの分散トレーシング、ALBのトラフィックコントロール、『AWS CodeDeploy』が提供するようなブルーグリーンデプロイメントやカナリアデプロイなどで対応できるケースは多くあります」

　そもそもサービスメッシュが解決しないマイクロサービスの課題もあるという。例えば、「マイクロサービス化によって生まれる複雑性への対応はビジネス的に対価に見合うのか」「API仕様だけを信頼し、相互に実装していく組織に変革できるかどうか」「APIの後方互換性を保つ強い意思を持てるのかどうか」などだ。「これらに立ち向かう価値があるかどうか、マイクロサービスやサービスメッシュが自社のシステムに本当に必要かどうかをきちんと検討してほしい」とHara Tori氏は訴えていた。

Copyright © ITmedia, Inc. All Rights Reserved.

[an error occurred while processing this directive]
ページトップに戻る