CNDT2021、クラウドの複雑さを解消するための指針を解説するセッションを紹介

CloudNative Days Tokyo 2021から、複雑になりがちなクラウドネイティブなシステムに対処する方法論を解説するセッションを紹介する。セッションを担当したのは、クラスメソッド株式会社のソリューションアーキテクトである寺岡慶佑氏だ。

「クラウドネイティブの複雑さに向き合うあなたに」というタイトル

寺岡氏は、このセッションでは技術的な内容には踏み込まずに解決すべき問題への取り組み方、組織の作り方などについて解説することで、これからクラウドネイティブなシステムに取り組もうとしているエンジニアに向けて何を準備すれば良いのか？ を伝えた形になっている。

開発するアプリケーションが徐々に複雑になっていく過程を説明

最初の例ではロードバランサーとアプリケーション、そしてデータベースというシンプルなアプリケーションが、開発の拡大によって徐々に複雑なシステム構成に移っていくようすを説明し、最初はシンプルでもいつの間にか複雑になってしまうことを説明。

複雑化はクラウドのせいではない

しかしシステムが複雑になるのは使っている技術のせいではなく、もともとシステムを取り囲む社会やビジネス、精度が複雑だからであるとして、システムはビジネスや社会を反映したものであるという見解を紹介した。

クラウドネイティブの定義を再確認

ここでCNCFによるクラウドネイティブの定義を引用し、特にスケーラブルなアプリケーションを構築実行する能力と回復性、管理力、可観測性のある疎結合システムであることが重要だと説明した。

自ら定義を解釈して応用する必要があることを強調

しかしCNCFのソフトウェアを使うだけではなく自身の問題解決にどうやって応用するのか？ これを解釈する必要があることを強調した。

また「スケーラブル」の本当の意味は、単に拡大できるだけではなく変化に容易に対応できることであり、こちらのほうが重要だと説明。

そのためには疎結合であることが重要

そのためにはシステムが疎結合で構成されていることが重要であると解説。疎結合であることでテストが容易になり、本番へのデプロイについても依存を減らすことでデリバリーの頻度や速度を向上させることができると説明した。

スケーラブルなアプリケーションは疎結合が重要

そして社会や精度を反映した形で複雑になりがちなシステムについて、システム開発の視点で分解するスライドでは、以下の3点の「曖昧さ」を挙げ、その対処方法を解説した。

• 利用する技術や目的が曖昧である
• システムに対する責任が曖昧である
• 導入の効果が曖昧である

複雑になってしまう要因を挙げて解説

最初の目的が曖昧という問題への対処については、Googleのエンジニアが実行しているデザインドキュメントを書くという方法を紹介した。これはソフトウェアの仕様を記述するものではなく、目的などについてプロジェクトに先立って作成されるドキュメントであるという。あらかじめ目的を明らかにする点では、Amazonでは新しいことを始める前にプレスリリースを書いてステークホルダー全員の承認をもらうというのも、同様の仕組みと言えるだろう。

目的を曖昧にしないためにデザインドキュメントを書くことを推奨

またチームの責任が曖昧になってしまうという部分に関しては、システムの境界とチームの責任の境界を同一にすることで、どこからどこまでが開発チームの責任範囲なのかを明確にできると説明した。興味深いのは、ここで疎結合なマイクロサービスは必ずしも必要ではないという部分だろう。実はこの前に、変化に強いアプリケーションを実装するためには、モノリシックよりも疎結合なマイクロサービスのほうが適しているという説明があったところだ。

その背景には、マイクロサービスで開発することでチームが細分化され、チーム間のコミュニケーションコストがメリットを上回るような場合や、マイクロサービス間通信のエラーハンドリングなどのオーバーヘッドが増大してしまう場合も有り得るからだ。よってここで「そのような状況においては」という但し書きが必要だろう。

寺岡氏がこのスライドにある別のプレゼンテーションで紹介している「モジュラモノリス（modular monolith）」というモノリシックなアプリケーションの中を分割して開発する方法論も検討するべきだろう。最初からマイクロサービスを開発するのはアンチパターンであり、モノリシックなアプリケーションを徐々にマイクロサービス化するべきだという指摘は、クラウドネイティブなシステムを目指すエンジニアにとっては重要な指摘だ。

チームの責任を明確に。モノリシックなアプリケーションでも可

またチームにオーナーシップを持たせるための具体的な方法論について、アカウントの管理、Kubernetesのnamespaceなどを例に挙げて説明した。ここではあえてエンジニアに馴染みのある用語を使うことで、具体的な方法を示唆していると言える。

チームを集中させる方法を解説

また効果測定は継続的に行うことが重要で、その結果からの改善についても継続することが重要だと説明し、では継続的な改善には何が必要か？ を解説するスライドに移った。

導入効果の曖昧さを解消するためには効果の観測が重要

組織が継続的に改善を行えるようになるためには、組織に属する個人が継続的改善を行うことを明文化しなくても組織文化としてそれが実現できるように変化していくべきだと説明した。しかし人間は常に楽な行動を取りがちな生物である。個人個人による継続的改善というルールにも書かれていない面倒な作業を横に伝搬させるためには、なんらかの工夫が必要であろう。

個人の継続的改善が組織文化となる？

そのための工夫を解説したのが次のスライドだ。

継続的改善を持続させるヒント

ここでは改善するべき課題を記録して共有する、簡単な部分から少しずつ始める、改善の効果を記録するなどが挙げられている。

ソリューションアーキテクトの立場でより技術的な側面を深堀りすることも可能だったと思われるが、あえてそこを避けて抽象的な内容に絞ったのは、クラウドネイティブなシステムが目的化してしまうことで本質的な「課題解決」というテーマがぼけてしまうことを懸念したためだろう。マイクロサービスのアンチパターンについては、別のスライドでより深く解説されているので参照されたい。

参考：あなたの組織にとってマイクロサービスは本当に必要ですか？ / Why YOUR organization should NOT choose Microservices Architecture.