(サービスを利用する側)にとって破壊的な変更になっていないかを早期に発見する仕組みです。守られていることをテストを通して検証し、保証します。哲学として実装する考え方です。others.(あなたがやることはコンサバティブに、他者からの受け入れはリベラルに。返される応答メッセージに対しては必要なフィールドにのみアクセスするようにします。側によるサービスの進化や変更に対して強くなり、チームの独立性を維持することができます。時間体制でソフトウェアシステムを運用し、昼夜問わずに発生する問題に直面すると、高いサービス品質を実現するコードを書くという志向をチーム自身が持つようになります。その例として説明しています。して世界に公開しています。恩恵を受けることができます。このような文化が、標準化に重きを置かない、マイクロサービスを志向するチームの哲学を徹底した例です。この哲学を実践するチームは、直面する課題に対し、ドキュメント化された標準に従うのではなく、その解決法をコードに落とし込み、他の開発者も利用できるツールとして共有することを好みます。コードの中にビジネスドメインを含みません。様々なチームで利用することが可能であり、それを利用したチームの独立性を阻害することもありません。使うかどうか自体、チームの自由意思に委ねられます。定めるデータモデルには、「概念スキーマ」「論理スキーマ」「物理スキーマ」という三通りのインスタンスがあります。このセクションではこれらのうち、概念スキーマと論理スキーマのあり方が、主なテーマとなっています。概念スキーマ(概念データモデル)は、モデリング対象となる領域(ドメイン)を表現した実体クラス(と関連)の集合です。いったイベントを表すものがあります。一方の論理スキーマ(論理データモデル)とは、概念データモデルを、データを扱うための任意の技術にあわせて構造化/表現したものです。リレーショナルデータベースを使うなら、テーブルやビューとしてデータを表現することになります。モノリシックアーキテクチャでは、ひとつの概念スキーマをもとに、リレーショナルデータベース用の論理スキーマを定義することが多いのではないでしょうか。扱うビジネス領域(ドメイン)が大きければ大きいほど、ひとつの概念スキーマで全てを上手く表現することが難しくなります。それらを扱うユーザーの担当領域によって、同じ言葉が指す概念が違っていたり、扱いたいリソースやイベントの単位が異なるからです。同じドメインを扱っていても、コンテキストによって、概念やその表現方法が異なるということです。これを無理にひとつの概念スキーマに押し込めようとすると、実体クラスがファットになり過ぎたり、逆に細分化されすぎて、ユーザーにとってもデベロッパーにとっても扱いにくいものになりがちです。この問題への解決は、それぞれのコンテキストごとに概念スキーマを分離して定義することです。パターンの考え方で、マイクロサービスアーキテクチャとも相性が良い手法です。サービスの分離は、つまりコンテキスト境界による分離であり、これがビジネスケイパビリティの凝集度をより高めるからです。概念スキーマが分離されたので、論理スキーマも分離するのが自然な流れです。マイクロサービスアーキテクチャでは更に、データ永続化に使用する論理データストレージ自体も分離します。同一のデータストレージミドルウェアのそれぞれのデータベース領域を使うこともあれば、異なるインスタンスを使うこともあります。そもそも各々が異なるミドルウェアを使うこともあります。Persistence)。これまで単一の論理データストレージを使っていたデベロッパーなら、データベースを分離したことによって、一貫性の保証がどうなるのか気になるところです。Consistency)を選択します。問題が生じた場合はオペレーションで補完します。これはトレードオフで、強固な一貫性を実現し運用する中で失うコストより、オペレーションによる補完や補償の方が小さいという考えに基づきます。Automation(インフラストラクチャーオートメーション)マイクロサービスアーキテクチャで構築されたソフトウェアシステムの多くは、自動テストを含むビルド、デプロイ、運用の複雑さを軽減するために、インフラストラクチャの自動化技術を幅広く活用しています。お話で、マイクロサービスに特化した内容はほとんどありません。クラウドのアーキテクチャ設計は、障害発生を見越した悲観的な視点に立つべきで、障害から自動的に復旧できることが望ましい、と書かれています。Recovery)を重視すると言えます。モノリシックアーキテクチャのインプロセスでのファンクションコールに対し、マイクロサービスアーキテクチャでのリモートによるサービス利用は失敗する可能性を常に抱えています。これは、通信経路上の問題の場合もあれば、コールされたサービス側の問題の場合もあります。いずれにせよ、マイクロサービスアーキテクチャでは、リアルタイムモニタリングを通じて障害を即座に検知する仕組みが重要になります。モニタリング対象となるのは、システムメトリクス(例:データベースが秒間毎にいくつのリクエストを受け付けたか)や、ビジネスメトリクス(例:分間毎にいくつの注文を受け付けたか)、サービスの死活などで、ダッシュボードを活用していつでも確認できるようにします。システムの信頼性に関し、マイクロサービスアーキテクチャで課題となるもうひとつのポイントは、本番環境と同じ環境を、テストのために用意することが難しいという点です。独立した複数のサービスの頻繁なデプロイが、この状況を生んでいます。Monitoring)という考え方があります。自動テストのサブセットを本番環境で実施し、テスト結果をモニタリングするというものです。実践している、本番環境でのカオスエンジニアリングです。彼らは就業時間中に、本番環境のサービスやデータセンター全体を意図的に落とし、システムが過酷な状況に耐えられることを日々、自動テストしています。アジャイルソフトウェア開発宣言)アジャイル開発では綿密な計画の作成より変化への対応を重視します。この哲学が核となっています。design(進化的設計)の本質を紐解いています。ほとんどのソフトウェアシステムは、そのライフサイクルにおいて変化していくものです。これには問題点はいくつかあります。プログラミングで対処しなければならない問題を、設計段階において全て見通すことは不可能です。ここで見逃された問題はプログラミングの段階で出くわすことになります。ここでプログラマーが局所的な対処を取ってしまうと、コードのエントロピー増大につながります。逆に大局的な視点に立って設計からやり直していると、時間とコストの増大に繋がります。時間とコストを無制限に使う訳にはいきません。結局は、制約の中で出来る範囲で設計の見直しをやることになり、これがまたエントロピーの増大につながってしまいます。困難にすることと言えば、「要求は変化する」という現実です。対処方法として、「どのような変化が起きるか」を洞察し、それを柔軟性(flexibility)として設計に組み込むことが考えられます。将来の変化を完全に読み切ることは不可能です。予測していなかった変化による変更も起こり得えます。予測が外れて使われないままのコードも出てきます。そもそも、使われるかどうかもわからない柔軟性を持たせた設計やコードが、新たな機能追加などに要するコストを増大させてしまいます。要求を十分に理解しきれず問題を引き起こすこともあります。要求定義プロセスにフォーカスをあてることで、これを回避しようと考えるかもしれません。要求の変化は、ビジネスの変化からもたらされることが多く、要求定義を強化したところでこれを完全に防ぐことは出来ません。ソフトウェアシステムの実装が進むにつれ、設計も成長していくことを意味しています。設計はプログラミングプロセスの一部として実施されます。実効性を高めることが出来ます。テストと継続的インテグレーションは、加えた変更の安全性を保証するために欠かせません。バランスを取るために使えます。完全に無くなることはありませんが、そちらのウェイトを軽くすることで、リファクタリングという手法によって後からコードに(洗練された)設計を組み込む時間を捻出することが可能となります。ソフトウェアシステムを、その時点で必要最低限なシンプルな状態を維持し(YAGNI)、変化を受け入れるコストを最小限にしようと努めます。迅速かつ頻繁にソフトウェアの変更を適切に実施することを目指すアプローチです。このアプローチを、サービス分割の切り口としても見ています。このサービス分割という設計行為も、全てを見通して行うことが不可能だからです。運用を続ける中で漸進的に成長させる方が現実的でしょう。ウェブサイトのように、モノリスとして構築され、マイクロサービスとして進化しているアプリケーションがその例です。逆に、同時に変更することの多い二つのサービスをひとつにまとめるようなケースもあり得ます。長期的に運用するサービスではなく、一時的に立ち上げて、必要がなくなったら削除するようなサービスもあるでしょう。このような斬新的な進化は、サービスのコンポーネントとしてのモジュール性を高めることに繋がります。言えるのではないでしょうか。支えてくれるでしょう。TolerantReader最後にブログ記事としてはなかなかの長文になりましたが、いかがだったでしょうか。読み直したことで、全体の関係性や、背後にある技術やプラクティス、パラダイムなどについて、より深く理解できるようになったと感じています。マイクロサービスアーキテクチャの追求とは常に、「それは、コンポーネント(=サービス)の独立した交換とアップグレードを推進するか?」と問いかけることだ、というのが私の結論です。これは、ソフトウェアシステムに対してだけでなく、チーム編成やプロセス整備に対しても適用される原理です。今回のブログ記事では、この数年で当社が得た知見などもあわせてご紹介したかったのですが、記事のボリュームをこれ以上大きくするのも良くないので、また別の機会にと思っています。Codeのフォーマッタを自分好みに設定してみる。