Monolith to Microservices Chapter 2. Planning a Migration

移行をどこから始めるか、変更を管理するか、どのようにチームメンバーと進めていくか

そしてそもそもマイクロサービスで良いのか

ゴールを理解する

マイクロサービスはゴールではない。合理的な意思決定に基づく意識的な決定であるべき

「マイクロサービスが Netflix に適しているなら、我々にも適している！」というのはアンチパターン

何を達成したいのかをよく理解しないまま採用を決定した多くのチームに出会ってきた

理由が明確でない場合の問題

人やお金が必要

機能追加よりも移行作業を優先させるという大きな投資が必要

メリットを実感するまで時間がかかる

ROI (投資収益率) を求められることがあるが、この種のものに関する詳細な研究は殆どなく、あったとしても文脈が違いすぎて転用できない

3 Key Questions

何を達成したいのか？

代替案は検討したか？

移行がうまくいっているかどうやって知るのか？

なぜマイクロサービスを選ぶのか

なぜマイクロサービスが世界中の企業で採用されているのか

それぞれマイクロサービス以外の方法はあるのか

チームの自律性を向上させる

小規模なビジネスユニットを機能させるには、権限と責任を与える必要がある

ほとんどの現代的な組織は、組織内でより自律的なチームを作ろうと考えている

アマゾンのピザ２枚チーム、Spotify モデルなど、他の組織モデルを真似ようとしている

正しい方法で行えば、自律性は人々に力を与え、ステップアップと成長を促し、仕事をより早く終わらせることができる

チームがマイクロサービスを所有し、そのサービスを完全にコントロールできるようになると、より大きな組織の中で持てる自律性の量が増える

他の方法は？

コードベースの一部の所有権を異なるチームに委ねる

マシンのプロビジョニングにセルフサービス方式を採用

市場投入までの時間短縮

個々のマイクロサービスに変更を加え、リリースの調整を待たずにデプロイができると、より迅速にリリースできる

他の方法は？

ソフトウェアのデリバリに関わる全てのステップを思い浮かべる

各工程にかかる時間、経過時間、作業時間を確認し、それぞれの問題点を浮き彫りにする。並行して試せる多くのことが見つかるはず

負荷に応じたコスパの良いスケーリング

処理を独立してスケールさせることができる

ボトルネック部分のみをスケールアップさせれば良い

他の方法は？

より大きなマシンを利用する

垂直スケールには限界があるが、短期間での迅速な改善のためには無条件に否定するべきではない

モノリスでも水平スケールは非常に効果的

採用している技術をより負荷に対応できる代替品に置き換える

ロバスト性の向上

*ロバスト性とは、様々な外部の影響を受けにくい性質

一部機能のシステム停止の影響は大幅に拡大する可能性がある

シングルテナントソフトウェアからマルチテナントへ、など

機能が分解されるため、より堅牢なアーキテクチャを実装することができる

ある機能に影響が出てもシステム全体がダウンすることはない。

堅牢性が最も要求されるアプリケーションに労力を集中できる

レジリエンスとの比較

障害発生時に素早く回復する能力

組織が全ての潜在的な問題を予測することができないという事実に備えるプロセス

カオスエンジニアリング

ただし、マイクロサービスは必ずしも堅牢性を提供するわけではない

むしろネットワーク切断やサービス停止に耐えられるシステム設計が必要になる

他の方法は？

モノリスの複数のコピーをLBやキューなどの後ろで実行させておき冗長性を持たせる

multi-region, multi-zone など

より信頼性の高いハードウェア、ソフトウェアに投資する

手動プロセスへの過度の依存をなくす

開発者のスケール

開発者を増やして早く進めようとすることはしばしば裏目に出る

境界を明確に識別し、マイクロサービス間の結合を制限することに重点を置いたアーキテクチャを採用することで、独立して作業できるコードの断片が生まれ、スケールできる

チーム自体の自律性を十分に高める必要がある

マイクロサービスを持つだけでなく、各チームがどのように連携しどのような調整が必要か考える

他の方法は？

モジュラモノリス

ただし結局デプロイには適切な関係者間の調整が必要

新しい技術の採用

モノリスは選択肢を制限する

通常１つの言語、イディオム、プラットフォーム、OS、DBを利用する

技術の変更をサービスの境界に分離することで、新しい技術の利点を個別に理解することができ、問題があっても影響を限定できる

成熟したマイクロサービス組織は、サポートする技術スタックの数を制限することはよくある

新しい技術を安全に試すことができる柔軟性は

顧客により良い結果をもたらす

新しいスキルを習得することで開発者を満足させる

競争上の優位性をもたらす

他の方法は？

新しい言語を同じランタイムに導入

JVM

DBは何らかの方法で分解し段階的な移行を可能にする必要がある。複雑で高リスク

新しいモノリスに段階的に置き換える

マイクロサービスが悪手になるのはいつか

不明確なドメイン

サービスの境界を間違えるとサービス間の変更が多くなり、モノリスよりも悪くなる

チームがドメインについて深く理解したとき、その安定した境界を見つけることができる

SnapCI

CDツール分野での経験があったため、境界を特定してシステムを構築したが、数カ月後、ユースケースが微妙に異なることが明らかになる

サービス間で多くの変更が行われ、変更コストも高くなった

結局チームはサービスを統合して、境界がどこにあるかよりよく理解する時間を設けた

一年後、マイクロサービスに分割でき、その境界がより安定しているものに

特にそのドメインに新規参入する場合、既存のコードベースから移行するほうがずっと簡単

もしそのドメインについて完全に把握していないなら、システム分解にコミットする前にドメインモデリングする

スタートアップ

マイクロサービスで有名な企業の多くがスタートアップなので、議論の余地があるように思えるかもしれない

しかし実際には Netflix や Airbnb などを含む企業の多くが、後半になってから移行した

「製品と市場の適合性の基礎を確立し、収益性を高めるためにスケーリングしている」スタートアップにとって素晴らしい選択肢

実際のスタートアップは資金が限られた小さな組織で、PMF(Product Market Fit)に全神経を集中させる必要がある

マイクロサービスは、スタートアップとして最初の成功を収めた後に得られる種類の問題を解決する方法

最初は成功することに集中すること。最初のアイデアがだめならそれをマイクロサービスで作ろうが関係ない

スタートアップが作るようなシステムで最初からマイクロサービスにするより、モノリスを仕切るほうがずっと簡単

コードの調査

システムの把握

本番での挙動の理解

マイクロサービスでは厄介なパフォーマンスの問題が発生することがある

スタートアップにマイクロサービスを導入するなとは言わないが、慎重になるべき。最初に明確な境界があるものだけを分割し、残りはよりモノリシックで維持する

カスタマーにインストールしてもらう形式のソフトウェア

一般に、特定のプラットフォームをターゲットとする

マイクロサービスアーキテクチャはインストール手順が複雑になる

顧客が Kubernetes クラスタを使えるか？

正当な理由がない

何を達成しようとしているのか、明確な考えを持っていない場合

トレードオフ

これまで単独で採用したい理由を説明してきたが、現実は多くのことを同時に変えようとしている。優先順位が混乱し、必要な変化の量が増えていく

始まりはトラフィックの大幅な増加

アプリケーションを再構築する必要があり、マイクロサービスが進むべき道であると判断

他の人がやってきて、同時に自律性を高めることができる！と言う

更に別の人が、プログラミング言語として Kotlin を試す絶好の機会だ！と言い出す

気がつけばそれぞれの変革が一度に行われ、他の事柄も進められる

このような状況では、マイクロサービスがアプローチとして固定化されてしまう

マイグレーション中に、モノリスを水平スケールさせたほうが良いということに気づくかもしれないが、チームの自律性向上や Kotlin の導入はできない

中核的な推進力を、二次的な利益と切り離すことが重要

今回はアプリケーションのスケールを向上させることが最も重要。他の目標が邪魔になったり重要な目標を見失うなら後回しにするべき

適切な優先順位。

スライダーを利用して優先事項のバランスを取ることができる

https://gyazo.com/196fe49d65a1cef655661faad95f0988

これらは変化する可能性があるが、意思決定の指針として役立つ