azure-recipe-user はじめに
Azureクラウドアプリケーションアーキテクチャガイドより、7つあるアーキテクチャスタイルの一つ、マイクロサービスに関してまとめます。
※前回記事
Azureアーキテクチャガイドまとめ 1 【はじめに】
Azureアーキテクチャガイドまとめ 2【N層】
Azureアーキテクチャガイドまとめ 3 【Webキューワーカー】
対応するAzureサービス
今回はやや長くなるので、最初にマイクロサービスアーキテクチャで活用されるAzureサービスをまとめます。
サーバレスであればAzure Functions、コンテナであればAzure AKSがコアサービスになります。
どちらの場合も、以下のコンポーネントで構成されます。
・サービスを体現するコンポーネント
・ドメイン駆動設計でいうモデルを実装しているアプリケーションが動作するコンポーネント
・管理
・サービスのノードへの配置
・障害の発見
・ノード間でのサービスの再調整
・サービス検出
・サービスとそれが配置されているノードのリスト保持
・サービスのエンドポイントを知るためのサービス検索機能
・APIゲートウェイ
・クライアントのためのエントリポイント
・クライアントをサービスから分離
・Webと親和的ではないメッセージングプロトコルでも対応
・横断的機能の実行
・認証
・ログ記録
・SSLターミネーション
・負荷分散
コアサービスとともに併用されるサービスも一覧にしておきます。
構成図にするとこのような感じ。
ちょっと寄り道
どんなサービスがあって、どのように組み合わせるのか、おぼろげながらイメージできました。
数あるサービスの中でも専門性が高く、しかも進化が続いているアーキテクチャだけに、ガイドだけだとなかなか理解が進まなさそう、というのが正直なところ。
そこで、いったんガイドを離れ、理解が進みやすいような情報をつまみ食いしようと思います。
ドメイン駆動設計って何ぞ？
マイクロサービスアーキテクチャの設計で避けて通れないのが、ドメイン駆動設計 (Domain-Driven Design, DDD)。
設計の勘所はAzure公式ドキュメントに網羅されているのですが、専門用語が多く、頭になかなか入りません。
そこで、こちらの記事を参考にさせていただき、概要を図示しました。
先の表や後述する内容と重複しますが、マイクロサービスアーキテクチャには多くの利点がある反面、仕組みも管理も複雑になりやすいという傾向があります。
しかも、ドメインにフォーカスし続けて開発するためには、ステークホルダー間の認識の祖語を最小限にするメソッドを明示しておく必要があります。
この開発手法を体系化したものがドメイン駆動設計、と理解しました。大枠はこれで大丈夫(のはず)。
サーバレスとコンテナの比較
Azureアーキテクチャセンターにサーバレスとコンテナの比較がありました。革新が早い技術ですので、とりあえずベースラインの知識として頭に入れておきたいところです。
概要
さて、ここでガイドに戻ります。アーキテクチャスタイルの特徴を挙げてみましょう。
・小規模な自律的サービスの集合
・各サービスは自己完結型で、疎結合
・各サービスは別個のコードベース
・各サービスは明確に定義されたAPIを使用して互いに通信
具体的には、以下のような特徴を持つアプリケーションに適しています。
・高速なリリースが必要
・大規模
・高い拡張性が必要で複雑
・多様なドメインや多数のサブドメインを持つ
・複数の小規模な開発チームから構成される組織によって作られる
利点
・独立した展開
・アプリ全体を再展開せずにサービスを更新
・バグ修正と機能リリースの管理の容易さ
・独立した開発
・継続的なイノベーションの実現
・リリースのペースを速める
・一つの開発チームが、サービスの構築、テスト、展開を行える
・小規模な専任チーム
・チームは一つのサービスに専念
・コードベースが分かりやすくなり、新しいチームメンバーでも理解しやすい
・障害の分離
・サービスがダウンした場合でも、その部分以外はサービス継続できる。
・とはいえ、回復性が自動的に得られるわけではない点に留意。
・テクノロジスタックの混在
・各サービスが違ったテクノロジスタッフ、フレームワークを持つことを許容する
・つまり、特定のサービスに最適な技術を選定できる
・きめ細やかな規模拡張
・各サービスは独立に拡張可
・マシンリソースの効率的活用
課題
・複雑性
相当する、複数の機能を持った単一のアプリ(モノリシックアプリケーション)に比べ、多くの可動部分があり管理が複雑
・開発とテスト
既存のツールは、サービスの依存関係を考慮するように設計されていない場合あり
サービスの境界を超えるリファクタリングが困難な場合も
特にアプリケーションが急速に進化している場合には、サービスの依存関係テストは困難に
・ガバナンスの欠如
使用される言語やフレームワークが多くなりすぎるとアプリの保守が困難に
特にログ規則などの横断的機能に対して、何らかの基準を設けたほうが良い
・ネットワークの輻輳と待ち時間
サービス間通信の増加で待ち時間が増える可能性
適切な場合には、非同期通信パターンを使用すること。
・データ整合性
各サービスが自身のデータ永続性に責任を負う必要がある
可能な場合は、結果整合性を採用する
・管理
成熟したDevOpsカルチャーが不可欠
サービス間でのログの相関が課題になることも
・バージョン管理
慎重に設計しないと、過去または将来との互換性に問題が生じることも
・スキルセット
チームに成功のためにはスキルと経験が求められる
ベストプラクティス
・ビジネスドメインを中心にモデル化する
・すべてを分散する。
・設計と構築には、個々のチームが責任を負う
・コードやデータスキーマの共有は避ける
・サービスは疎結合にし、機能の凝集度を高くする。
・二つのサービス間の通信量が多すぎる場合は、結合が密で、凝集度が低い可能性あり
・障害を分離する
・データストレージ
・データを所有するサービス専用にする
・データの種類に応じてストレージを選択
・API
・サービスの内部実装ではなく、ドメインをモデル化する
・ゲートウェイ
・認証やSSLターミネーションなどの横断的な作業を行う
・ドメインの知識を持ち込まない
まとめ
マイクロサービスの特徴と使用されるサービスについて見ていきました。いやー難しい。次回はCQRSアーキテクチャスタイルについてまとめます。お楽しみに！
参考リンク
Azureアーキテクチャセンター
Azureでのマイクロサービスの実装
ドメイン駆動設計は何を解決しようとしているのか[DDD]
