マイクロサービス実践のポイントの部分はよかったですね。
don't even consider microservices unless you have a system that's too complex to manage as a monolith.
https://martinfowler.com/bliki/MicroservicePremium.html
基本方針
対象システムが複雑である場合：マイクロサービス化を検討する
対象システムが単純である場合：マイクロサービス化には向いていない
モノリス・スタイルのアプリケーションを段階的にマイクロサービス・スタイルに置き換えるプラクティス
初回のアプリケーション開発時：従来通りモノリス・スタイルで開発
繰り返し開発/保守時：マイクロサービス・スタイルで開発
http://martinfowler.com/bliki/MonolithFirst.html
チーム・スケールの目安
2枚のピザ・ルール
Spotify
スクワッド (Squad) : 約 8名
トライブ (Tribe) : 50 Squads (≒400名)
[参考] サービス化どう進める?：Spotifyのチーム編成
トライブ (Tribe)
一番大きな組織体。ある特定の独立した対象(製品、サービス等)に責任範囲とする。
スクワッド (Squad)
個別のビジネス要件、まとまった機能 (Spotifyではこれを"Product"と呼ぶ)の開発・運用に責任を持つ。
8名程度。
チャプター (Chapter)
各スペシャルティ毎に設定される人事上の組織体。
各スクワッド・メンバーは、人事上はチャプターに属す。
ギルド (Guild)
特定のスペシャルティをテーマとする組織横断のコミュニティ。
自身が属すトライブ, スクワッド, チャプターを問わず参加可能。
BFF/API Gatewayの粒度
クライアントのタイプあるいは種類の観点での検討
原則クライアント種類毎に1BFF設置を推奨
クライアント・タイプ毎に1BFF設置した場合
BFFの種類が多くなりすぎ、メンテナンスのボトルネックになる懸念がある
One-size-fits-allの場合
BFFが大きくなりすぎ、メンテナンスのボトルネックになる懸念がある
トランザクション処理 : 複数リソースの同期処理
Saga パターン
複数リソースの同期を取るデザイン・パターン
ローカル・トランザクション, イベント, 補償トランザクションを活用
sagaを使用したマイクロサービスのデータ一貫性
マイクロサービスの配置パターン
1コンテナーあたり、1つのサービスをデプロイする
各サービス毎(≒ビジネス毎)のメンテナンスが可能。
よりきめ細かなスケーラビリティ調整が可能。
コンテナのエッセンスは、PaaSのシンプルさとIaaSの柔軟性のいいとこ取り
PaaSには無い"容易で柔軟なカスタマイズ性"がコンテナの売り
アプリ開発に加え、M/WやOSレベルの環境整備が求められる。
M/W、OSレベルのカスタマイズが容易。
Dockerコンテナ間通信
コンテクスト：複数のコンテナ間で通信する必要がある。
例) AppServerコンテナとDBコンテナ。
課題：通信相手のコンテナのアドレス解決。
コンテナのデプロイ時に初めてコンテナのアドレスが確定する。
アプリケーションが事前にコンテナのアドレスを知ることは出来ない。
解決策：Dockerネットワークの利用。
ネットワークを作成：docker network create
コンテナをネットワークに参加させる : docker run --net
コンテナ間通信では、アドレスの代替として
KubernetesはクラウドにおけるLinuxになりつつある
クラウド・ネイティブ・アプリケーション運用に必要な基盤機能を提供するのが、Kubernetesです
従来型ベア・メタル・サーバーにおけるOS(例えばLinux)のように
パッケージ管理
クラスタリング
スケジューリング
可用性
ネットワーク
セキュリティ
監視
...
Comments