クラウド化が与えたアプリケーション設計への変化
このように説明すると、メリットばかりでデメリットが少ないようにも感じます。であれば、どうしてかつてのシステム設計者はこのような構造をとらなかったのでしょうか。
そこには、インフラだけにとどまらず、サービスも含めたクラウド化によってシステム構築のおけるコストや設計など、あらゆる要素で全体最適化から個別最適化へ変わったためという要因があります。
例えば、統合型アーキテクチャが主流の時代では、事前に用意した不変なシステム資源をできるだけ効率的に利用する必要があるため、図3（左）のようにシステム全体にあわせたアプリケションの最適化が必要でした。そのためシステムでの機能毎の境界線や実行頻度やタイミングなども他の機能とのバランスを考えて設計する必要がありました。
一方、現在はこれらは仮想化などの技術によってより必要時に拡張しやすくなったために、図3（右）のようにシステム資源はアプリケーション側の都合に合わせて最適化すればよいという考え方です。これにより、必要とする初期コストも大きく下がりました。
このような変化により、アーキテクチャを考える上でさまざまな外部要因を排除した独立したシステムが作りやすくなったと言えます。
この違いは非常に大きく、フレームワークトレンドにも大きく影響を与えていると思われます。例えば、統合型システム時代のフレームワークはアプリケーション内部で区画化（独立性の担保やセキュリティ管理）をどのように実現するかという側面が強く、重厚でより強力な制御管理ができるフレームワークが好まれました。
一方、現在のフレームワークにはそのような考慮の重要性が低くなり、反面、素早くシンプルに実装ができるための軽量フレームワークが主流になっています。
マイクロサービス型システムでおきやすいトラブル例
マイクロサービスでは、各サービスが独立しているために生じる課題や問題もあります。例えば、想定しない問題が生じた場合、どこで生じた問題なのか、もしくは問題が生じているのかそのものが特定しにくくなる状況があります。
例えば、筆者が遭遇したあるECサービスでのトラブルを例に、具体的な問題を紹介します。筆者が携わったシステムではなく、消費者として遭遇したトラブルなのですが、機能または役割が独立していると起きやすい問題の典型といえます。
そのECシステムは購入履歴、現在購入した商品の配送状況、配送日指定、自分の住所や配送先情報の管理など、消費者として見た時には何の問題もなく、技術者視点でみてもよくできたシステムでした。
ところがある時、商品を購入しても予定通りに商品が届かないというトラブルに遭遇しました。システムの状況を確認してみると、購入した商品が届いていないにもかかわらず、出荷日は約1週間前であり、すでに配送伝票番号の通知メールも来ていました。しかし、実際には予定から2日遅れていても商品は届かないばかりか、システムで確認できる情報はその出荷日から何も更新されていませんでした。
そのときのサポート担当者やその後にとった関係者との連絡を元に、筆者が想像した状況が図4です。
最終的に分かった原因は、荷物が途中で紛失してしまったことでした。その紛失原因がデータ上の問題なのか、物理的な原因なのかは分かりません。しかし、実際のビジネスではシステムだけで顧客との窓口が完結している以上、システム外でおきた障害もなんらかの形でシステムに取り込む仕組みが必要です。
もっとも、誰も想定していなかった未知のトラブルに対してもシステムに取り込むのは現実的に不可能です。したがって、実際のビジネスでは問題が生じないことよりも、問題が生じたことが分かり、その状況の把握が容易であることが望まれます。
このようなケースを想定したときに、独立型システムで生じやすい以下のような課題点が見えてくるはずです。
- 独立したシステム毎にデータやステータス等の情報を持つため、状況の横断的把握や理解が難しい。
- システム間の横断的情報把握を解決しようとすると、各機能の独立性を保つのが難しくなる。
- 関連するシステムのすべてと問題なくデータや処理の同期、もしくは通信できる事を保証する事が難しい。
- トラブルがシステムの中間地点で発生した場合、そのトラブル解消や追跡の責任を持つシステムがどちらの責任範囲になるの判断しにくい。
- すべての単独システム単位では正常ケースであっても、全体としてはエラーケースになり得る場合がある。
この事例はより分かりやすいケースを紹介しましたが、実際のシステムでは説明や役割分担について人が判断しにくいところで、似たような課題は多々生じています。このように、実際には理想通りの独立・分散型のシステムアーキテクチャの実現は非常に難しいという課題があります。
