🈂️
マイクロサービス事例
失敗事例（事例というかサジェスト）
Github元CTO Jason Warner
https://twitter.com/jasoncwarner/status/1592227285024636928
- 伝えたいメッセージとしては設計段階で全てをマイクロサービスするアプローチは間違っていると言うこと。
過去10年間のアーキテクチャ上の最大の間違いの1つは、完全なマイクロサービスに移行しようとすることだと確信している。 モノリスからマイクロサービスまでのスペクトラムで、私は次のように提案する。
モノリス＞アプリ＞サービス＞マイクロサービス
まず、考え方はルールではなく状況に合わせて最適な方式を選択する必要がある。成功失敗は事後に判明する
ステージに応じて最適な方式を選択する必要があり、50人以下の会社であればモノリスを強く推奨する。
マイクロサービスが難しい理由は以下の通り
- マイクロサービスの分割方法などを議論するより、モノリスの１つのアプリをチーム全体で作業するほうが容易
- サービスが大きくなりにつれ分散システムが必要となるが、独自のリスクプロファイルを持つマイクロサービスを数十、数百導入するのは難易度が高い
- 完全にマイクロサービス化する際にはスプロール（無秩序に増えるマイクロサービスを管理、繋ぎ合わせるレイヤー）を処理する導入コスト、難易度が高い
- オーダーメイドされたインフラやマイクロサービスは技術的負債の最たるもの。必須ではないものに多くのコストを割くこと自体無駄
分散システムエンジニアは重複を避けたがるため、重複機能を切り出してマイクロサービス化しようと考える。これは理論的に正しく数十のサービス間では問題ないが、巨大企業の境界を超えるような場合、各ステークホルダーの主張もあるため技術的な挑戦ではなく組織的な挑戦となる。私の経験としては技術的課題もあるが、それ以上に組織的な課題がある
考慮・心配する点は以下の通り
- インフラは優先度が低くなる（ITの理解が乏しいCEOにありがち）
- サービスが増えすぎるとオーナーシップ、境界線の問題がある。誰もボールを拾わない
- 増えすぎたマイクロサービスに対処するために、さらに多くのツールと投資が必要となる
- コードが増えることはオーバーヘッドになるが、サービスが多いことは顧客体験に影響を与えどちらのアプローチでもオーバーヘッドは発生し、その割合が異なるだけ
推奨する方法は以下の通り
- 出来るだけ長くモノリスを続ける
- サービス化はインフラチームがインフラ要件で主導する
- モノリスから脱却する場合はなるべく大きなアプリに分割する
- アプリを増やすことは社内に新しい壁（コミュニケーションの妨げ）を作ると捉え慎重になるべき
- マイクロサービス化よりもライブラリの整備を優先する
成功事例（ド定番のNetflix）
マイクロサービス化の背景
- オンプレでモノシリックで稼働していたサービスが障害により数時間利用不可能となる
- 対応としてAWSへのリファクタリングを行い、DB分割、API化などを順次実施
- 最終的に500程度のマイクロサービス、30チームにて保守している
- 品質面の問題、デプロイ時間の短縮、スケールの問題、これらを解決するためにはマイクロサービスが最適だという判断に至った
- マイクロサービス化の対応は1年半（私の感覚だと短期間）
気づき
- 上記は2013年頃の出来事であり、Netflixはマイクロサービス化が目的ではなく、品質改善やUXの対応を起こったことが結局マイクロサービス化であったと感じた
Discussion