サービスのサイズとスコープの検討

技術においてマイクロサービスを構築するという逆らい難い流れがありますが、それには正当な理由があります。小さなコンポーネントは、モダンなアプリケーションのデリバリの手法と目的に対してとても相性が良いのです。ガートナーによると、ビジネスリーダー3人のうち2人は、競争力を保つためにはデジタル化の速度を早める必要があると考えています。その結果、多くのビジネスではソフトウェア配信のペースを上げる事に取り組んでいます。その為に、変更や障害による影響範囲の少ない、小さなコンポーネントを作るのは良い方法です。小さなコンポーネントはテスト、セキュリティ対策、安全なデプロイ、独立したスケーリングを行いやすいからです。Puppet Labsによると、小さなコンポーネントとDevOpsを組み合わせることで、デプロイの頻度が46倍になり、失敗率が1/5になりました。これらの利点はとても魅力的ですが、実際にマイクロサービスを構築することは複雑で新しい挑戦も必要になります。マイクロサービスは最新のトレンドですが、変更や機能追加、構成の理解や運用が容易であるという、モノリスの利点も無視してはいけません。モノリスでの開発を続けるべきというわけではありませんが、意図を持ってどの道筋や手段を取るかを選択する必要があります。

数年をかけて、我々は「サービス」や「サービス指向アーキテクチャ」から「マイクロサービス」へと進みました。この用語の変化は、サービスを構築する際にサイズが重要である事を暗示しており、それは一般的に正しいと思います。しかし、どれだけ小さな物が「マイクロサービス」なのでしょうか？サービスに対して正しいサイズを見つける事は、(科学ではなく)アートの分野であり、あなたにとっての優先順位が反映された物にならなくてはいけません。顧客の最優先で最重要な課題にフォーカスし、顧客を離れさせないために、ビジネスの俊敏性と革新性（イノベーション）を高める必要があります。その為には、価値をより高い頻度で届け、顧客のフィードバックや進化していく要望に適応できる必要があります。フィードバックに最善な対応をするには、(内外の)顧客の課題に精通する顧客が使用する製品を担当する人（チーム）が必要です。そうすることで、我々はそのチームに支援やインセンティブを与えることを通して、顧客の代わりに問題を解決したり、新しい方法を発明したりすることができます。

製品やサービスを担当するために、我々は通常5人〜10人程度の小さなチームを組織します。各チームは製品やサービスの1つのコンポーネントに責任を持ちます。そのコンポーネントはチームが発案から運用まで、一貫して担当できるくらい小さくなければいけません。もし、コンポーネントが単純で、1つのツー・ピザ・チームが複数のコンポーネントを所有できるようであれば、そうしても良いでしょう。しかし、複雑さが増すにつれて、1つのチームがコンポーネントを完全に担当できる様にするために、意識的にこれらのコンポーネントのサイズを小さくする（または、分割する）必要があります。

名前に意味はあるのか？

あなたの「モノリス」の定義に関わらず、多くの事をしようとしすぎてスピードを損ねている密結合のアプリケーションから抜け出そうとしている事は同じだと思います。「マイクロサービス」や「マクロサービス」、もしくは単に「サービス」と呼んでも本質的にはどうでも良いはずです。「Twelve-Factor App(訳注：アジリティのあるSaaSを開発する為の方法論)」はモダンアプリケーションの構造、設定、役割の分離について考える良い出発点となります。依存関係の管理、環境毎の設定、デプロイ、などに取り組むことで、アプリケーションの運用や変更がより行いやすくなります。私の考えでは、最初にこの12要素のアプリケーションを構築し、コンポーネントの粒度については後で考える事で、一般的なアンチパターンである「premature optimization(早すぎる最適化)」を避けることができます。

やりながら学ぶ

「迅速な実験と学習」を実現するための環境を作る上で、ソフトウェアを素早く開発しリリースする必要があります。サーバーレスは、企業がビジネスロジックのみに集中し、クラウドプロバイダーのビルディングブロックを活用してソリューションを簡単に構築できるようにすることで、その実現を支援しています。しかし、時には問題は複雑です。初期段階において、構築中のコンポーネントに対する、ユーザーのニーズ、データライフサイクル、スケーリングプロファイル、使用パターンについて、完全に理解や認識が不足することがよくあります。その場合は、各コンポーネントは長い工程(ジャーニー)の途中であると考えてください。コンポーネントはリタイアされるまで、改善に終わりはありません。やりながら、学んで改善する必要があります。サーバーレスとマイクロサービスに関する話題では、最初からすべてをできる限り小さくすることを勧めるかもしれませんが、最初は粒度の大きなアプローチから始めて、時間の経過とともに最適化と簡素化に焦点を当てる方がはるかに簡単になると思います。オーナーシップに基づいたチームを組織し、コンポーネントに対して責任を持ち顧客により良い価値を提供する為にそれを日々改善していくことをチームにコミットしてください。全てのユースケースをカバーし、完璧な粒度のサービスを作ることは時間がかかり、賢明な基礎作りの工程にも見えますが、それは必要なのでしょうか？そうではなく、コンポーネントを作る場合には、イテレーションを回し、縮小やリファクタを行い、実際に必要なコンポーネントを必要な時に開発する方法を取るべきです。

コンスタントに小さなイテレーションを回し、サイズについて心配するのを止めましょう。オーナーシップを持ち改善する事にコミットしてサービスを構築しましょう。

—ブライアン

Twitter | LinkedIn | Blogs

関連するトピック：
On-Demand Webinar: Modern Applications on AWS
Modernizing How You Build, Part 1—The Modern Application
Modernizing How You Build, Part 2—Taking the First Step
著者のブログ記事

著者について

ブライアン・ランダーマン

ブライアン・ランダーマン は 2019 年 2 月にエンタープライズストラテジストおよびエバンジェリストとして AWS に入社しました。この役割において、ブライアンは企業のエグゼクティブと協力して、クラウドがスピードと俊敏性を高めながら、より多くのリソースを顧客に捧げるのに役立つ方法についての経験と戦略を共有しています。AWS に入社する前は、ブライアンはコックスオートモーティブのCTO でした。

翻訳は Solutions Architect 多田が担当しました。原文はこちらです。