進化的アーキテクチャとは何か、どのように構築するのか

アクセンチュア株式会社　テクノロジー コンサルティング本部
インテリジェントソフトウェアエンジニアリングサービス グループ
マネジャー　高橋 悠輔氏

ビジネスルールの変化、テクノロジーの進化が日々加速する現代。ビジネス面では、高速なプロダクト開発と市場への投入がビジネスの成否を分けるため、サービスデザインから初期稼働と機能追加まで、高速、短期間に行える基盤が必要になっている。

一方、テクノロジー面では、その進化によって要素技術のトレンドは激変し、言語やミドルウェア、インフラなどを柔軟に交換できる基盤の提供が必要不可欠になっている。つまり、変化に取り残されることなく、柔軟に変化できるITアーキテクチャを構築することがより欠かせなくなっているのだ。

アジリティを維持しつつ、セキュリティを担保するためには、どのような思考の型でアーキテクチャを設計する必要があるのか。その思考の型のキーワードとして、まず挙げられるのが「進化的アーキテクチャ」である。この進化的アーキテクチャについて高橋氏が解説を行った。

「進化的アーキテクチャは、大きく3ステップに分けて考えます。その準備として対象とするビジネスの性質と、既存システムの成熟度を確認することから始める。スタートアップ、プロトタイプ、エンタープライズでできることが違うからです」（高橋氏）

第一ステップは「適応度関数」の設定だ。アーキテクチャが進化する中で守っていくべき非機能要件を抽出し、非機能要件を計測可能な数値に落として、テストする方法を実装するのである。

第二ステップは「漸進的な変更」である。計測の自動化によって、適切なタイミングで適応度関数を評価。そして適応度関数をデプロイの判断基準にすることで、進化の方向を誘導するのである。適応度関数とは「システムの非機能要件に進化しやすさを追加していくこと」である。

第三ステップは「適切な結合」。ソフトウェアやデータ、組織の結合を行う。

「この3ステップを踏むことで、その組織に実現可能なレベルでの進化的アーキテクチャが実現できます」（高橋氏）

今までの非機能要件はトレードオフを考慮しながら、アーキテクチャで重点的に解決する問題を決定していた。アーキテクチャが決まったら、それを変更することはめったにない。

一方進化的な非機能要件は、アーキテクチャで重点的に解決する問題を定めた後に、それを定量的に評価するために手段と基準値を設定する。適応度関数を導入することによって、ある非機能要件に対して、守るべき性能やあるいは指標を維持している限りにおいては、アーキテクチャの変更を許容してくれるのだ。

「非機能要件のトレードオフを考慮しながら、そのときどきに最適なアーキテクチャを設計することは変わりません。しかしアーキテクチャを設計し、デプロイした後も、適応度関数が改善されている場合に限って、アーキテクチャの変化を継続的に許容することができるようになります」（高橋氏）

次のステップ「漸進的な変更」は正攻法だが、次の図のようなCICDによる自動化パイプラインを実装し、適応度関数をステップ化することが必要になる。単体テストや結合テストで、コードの複雑さやモジュールの循環性などを評価する。

「セキュリティや耐障害性、スケーラビリティなどはシステムテスト以降、全体的なシステムとしての観測が必要になってきます。場合によっては本番環境でのテストを辞さないことも鍵となってくるでしょう」（高橋氏）

また、可用性や耐障害性ではカオスエンジニアリングが活用できる。例えば、サーバに障害が起きたり、リージョンが落ちたりしても大丈夫という対障害性の非機能要件を守っている限り、本番環境のシステムを変更してもいいという場合だ。実際に本番環境でシステムを壊しても自動復旧することを確認し続けることで、耐障害性を維持した上で変化のしやすさを担保している事例だ。

「非機能要件の設計が終わって、CICDパイプラインを構築し、システムや人を分割しておくと、その適応度関数に従った最適化が進みます。そのベストプラクティスをいくつか提示します」（高橋氏）

組織の適切な結合では、マイクロサービス化が前提の反コンウェイ戦略をとり、サービスに必要なメンバーを一つのチームに集める。こうすることで「デプロイのベロシティを高めることができる」と高橋氏。ソフトウェアの適切な結合では、モジュール化、レイヤー化、API化によってデプロイ範囲をサービス単位で分割する。

データの適切な結合においては、結合テーブルを追加するのではなく、スキーマ自体をアップデートしたり、マイクロサービス間に別々のデータベースを作成。Kafkaやメッセージキューイングで分割するなどの配慮が必要になる。ここまでの話をアーキテクチャの構成図にすると次のようになる。

「マイクロサービスアーキテクチャの方が、進化的アーキテクチャの流れに沿っている。ただし、それを支えるデータベースの分割、何らかのツールによるデータベース間の統合を担保することが必要でしょう」（高橋氏）

マイクロサービスやサービスベースアーキテクチャ、いずれを採用するにおいても、「これで良かったのだろうか」という疑問は常に出てくる。この疑問を解決する方法としては、「一度作ったモノを捨てて置き換えるという思い切りを持つことも大事」だと高橋氏は語る。それが犠牲的アーキテクチャである。

例えば、Twitterは迅速にサービスを市場投入するため、Ruby on Railsを採用し、サービスを開始したが、プラットフォームが人気になるにつれてシステム障害が頻発した。そこでTwitterはバックエンドをScalaベースのRPCに置き換えた。

「最初から進化的アーキテクチャを作り込むのではなく、MVP（Minimum Viable Product：必要最低限の価値を提供するプロダクト）の迅速な初期市場投入をするためには、アーキテクチャをまず構築し、その後、アーキテクチャを再構築することで進化的アーキテクチャに移行することが必要です。市場投入と品質向上を両立する好例だと思います」（高橋氏）

分散・複雑化する未来に対する次世代アーキテクチャ

アクセンチュア株式会社　テクノロジー コンサルティング本部
インテリジェントソフトウェアエンジニアリングサービス グループ
Emerging Technology　アソシエイト・ディレクター　角山 恵介氏

続いて角山氏が語ったキーワードは「分散型アーキテクチャ」だ。私たちの生活を支える社会インフラは、高い可用性を実現するため、分散型アーキテクチャが採用されている。

「交通インフラであれば、複数の路線、交通手段を用意することで、一つの路線が停止しても、目的地にたどり着く、耐障害性に優れた仕組みになっています」（角山氏）

同様にインターネットやDNS、CDNなどのITインフラにおいても、処理を分散させることで高い可用性を実現している。自社ITシステムにおいても、可用性を実現するには分散型のアーキテクチャで、複雑性を備えながらもそれを統制できる基盤を構築していく必要がある。システムを取り巻く開発/運用環境は次の図のように変化、複雑化している。

「従来は集中管理された開発と運用体制だったが、開発と運用の境界がなくなり、今はさまざまなロケーションで開発・運用が行われています」（角山氏）

変化スピードは従来よりも速くなり、人の流動性も高まっている。ITに関わる人たちも従来はIT専門部署や社内システム、専門のベンダーなどのIT関連職種だけだったが、今はあらゆる部署、マルチベンダーがシステムに関わるようになっている。

技術も従来はベンダー固有の技術だったのが、今は変化に対するオープンな技術が採用されている。このような状況に対応していく一つの選択肢が、マイクロサービスアーキテクチャである。

強固なマイクロサービスアーキテクチャの基盤を築くにも「ポイントがある」と角山氏。第一のポイントはすべてをコードで管理することだ。

「改善を積み重ねていくには、すべてをコードとして管理して、信頼できる唯一の情報源とすることです。コードにすることで、事前のレビューや検証、チェックなどDevOpsによる改善の自動化ができるからです。またコードは複製が可能なので、アーキテクチャ基盤の拡張も容易になります」（角山氏）

第二のポイントは、宣言型のアーキテクチャにすること。「もはやすべてを人だけでは管理できない時代」と角山氏は強調する。システムや機能がどうなっていてほしいかをコードで宣言するのである。

そうすることで、曖昧な状態のまま意図しない動作が発生したり、致命的な失敗が起こるリスクが低減できる。宣言をもとに、自動でシステム全体をその状態に収束させるアーキテクチャを採用することで、それにかかる工数を減らすことができるというのだ。

第三のポイントはデータの分散と結果整合性。「マイクロサービスアーキテクチャ上でデータベースをどのように扱うのかは、毎回悩むポイント」と角山氏は言う。だがここも開発や運用を加速させるという視点で考えていく必要がある。

細かく分けすぎると複雑になってしまうので、適切な粒度によるサービスと、そのサービスが必要とするデータを分割することが求められる。データの整合性についても、結果的に整合性が保てるよう、更新のインターフェースはべき等性を備えることが必要だ。

そしてビジネスの規模が大きくなっていくと、複数のサービスの更新が分断されてしまうケースがあるので、業務のユースケースや規模などの特性に合わせてSagaやTCCなどのデータ更新パターンを検討するのである。

ここで事例が紹介された。米国の医療系スタートアップ企業、Sesamecareでは2020年に新型コロナウィルス感染症の拡大が本格化してきたとき、主要顧客である小規模医療機関をサポートするためのプラットフォームを、マイクロサービスアーキテクチャを活用して約1週間で実現した。

「Google CloudやKubernetesなどを活用しながら素早く立ち上げ、運用しながら改善していったという事例です」（角山氏）

スケーラブルなマイクロサービス基盤のエッセンスをまとめると、次の図のようになる。これらのエッセンスについて、それぞれポイントとなるところについても解説した。

マイクロサービスがエッジへと広がることで、現実と相互作用する道が開かれるようになる。その事例として角山氏が紹介したのは、全米で人気のチキン専門店「Chick-fil-A（チックフィレイ）」だ。チックフィレイでは、Kubernetesをエッジコンピューティングに採用し、店舗のインテリジェンス化を図っている。

「より複雑になっていく未来に対しては、複雑であることを前提としたアーキテクチャが求められることを意識し、採用・投資していくこと。そしてシステムとしてのプリンシプルを定め、こうなってほしいと定義する。システムそのものの管理や持続性は極力自動化できる技術を採用し、複雑性を軽減することです」（角山氏）

自社の守りを固めた後は、免疫的セキュリティを考える

最後のキーワード、「免疫的セキュリティ」について解説したのは高橋氏だ。セキュリティは今も未来においても重要な課題であるのは変わらない。だが、運営されるシステムは協調関係にあり、単一システム内にも複雑な依存関係が存在する。

「もはや自分のシステムを堅牢化するという単体防御の考え方は通用しない」と高橋氏。だからこそ、全体的な責任をとる立場にいるリーダーは、「免疫や共生という生物的なキーワードでセキュリティを考えていくことが必要になる」と高橋氏は言う。

セキュリティがなぜ大事なのか。ビジネスにおいて戦略の立案や顧客との対話を成功させるには、次の図のようなステップで基盤の積み上げが必須となる。その土台を築くのが、セキュリティやデータ保護だからだ。

「基盤が崩れると、信頼の鎖が綻び、システム全体の信頼を毀損してしまう。だから基盤固めが大事なのです」（高橋氏）

だが、脆弱性はさまざまなところに潜んでいる。例えばNode.jsのNPM（Node Package Manager）もその一つだ。現在のOSSは、複数の小規模パッケージを積み重ねてパッケージを作るエコシステム上で構築されている。

その小規模パッケージの一つの開発者のGitHubアカウントが攻撃されたことで、悪意あるコードが埋め込まれた。これに依存する人気パッケージ経由で爆発的にマルウェア感染が広がった。このように私たちは脆弱性を抱えた環境で生きているということだ。

ではどのように信頼性を高めていくのか。「それも3ステップで高めていく」と高橋氏。それが次の図だ。

まずは自社の鎖を固めること。デファクトの規格に準拠する。ソリューションを導入し、車輪の再発明を防ぐことも重要だ。第二ステップでは、絶え間ない変化への対応をアーキテクチャに組み込む。

「業界のルールやデファクトが変わったときのセキュリティの対応を、開発から保守業務のプロセスに組み込むことが重要です」（高橋氏）

ここまで固めたところで、最後の第三ステップはテクノロジーの免疫系を使いこなすこと。OSSフレームワークの開発状況を把握し、必要に応じて投資を行ったりするのである。例えば第一ステップでデファクトに準拠するといったが、デファクトといっても次の図を見ればわかるように数多くある。

「設計をリードする人は、これらのキーワードが何を目的としているのか、プロダクトを守るためには何をすれば良いのかを考えて、日々の設計や監査に取り組む必要があります」（高橋氏）

継続的なセキュリティ担保のためには、アーキテクトは次の図にあるような3項目を意識する必要がある。

例えばソフトウェアの安全性を担保するため、導入するのがCICDパイプラインである。だが、「CICD自体も攻撃の対象になる」と高橋氏。つまり、ソフトウェアの安全性を守るだけではなく、CICDパイプラインの安全性を守ることも難しいというわけだ。

セキュリティの概念が変わったときに、どう対応していくのか。その具体的な事例として高橋氏が紹介したのがAppleのアプリトラッキングルール変更。これにより一部のSNSプラットフォーマーはアプリを土台から作り直さなければならない苦境に追い込まれたという。

「サービスが生き残るためにも、ルールの変化に対応できる状態を作ることが重要です」（高橋氏）

そして自社の守りができれば終わりではない。自社の外側の環境にも働きかけていく必要がある。つまりソフトウェアの免疫力を高める取り組みだ。まずはフレームワークの免疫力を見定めることである。

「何かあったときにきちんと修復されるであろう技術スタックを見極める選球眼が重要になります」（高橋氏）

OSSの免疫力と公共性を見定めるには、Googleやマイクロソフトなどが出資しているOSSセキュリティプロジェクト「Alpha-Omega Project」や米国国防省のOSSの調達方針が参考になる。

次に自社システムにワクチンを持ち込む。自社の製品の一部をさらし、場合によっては攻撃の対象にすることで、自社製品の安全性を高めていくのである。例えばTeslaは、自社製品および自社展開サービスなどにおいて、脆弱性を発見した人に報奨金を提供する取り組みを実施している。

「このような方法により、プロダクトのセキュリティを全体的に高めています」（高橋氏）

そして第三にテクノロジーの信頼を見定めた上で使いこなすことだ。例えば、国を跨る身分証明の仕組みなど、これまで物理的な世界で担保されていた信頼関係が、テクノロジーの進歩によって、根底から変化するかもしれない世界に我々は生きている。その可能性に注視して、プロダクトのセキュリティや安全性、それによって担保される信頼関係を考えていく必要があるだろう。

アクセンチュア　テクノロジーコンサルティング本部について
アクセンチュア募集職種にご関心をお持ちの方へ＜テクノロジー コンサルティング本部編＞ (accenture.com)
 
インテリジェントソフトウェアエンジニアリングサービス グループについて
Intelligent Software Engineering Servicesのキャリア・採用情報 | アクセンチュア (accenture.com)
 
アクセンチュアの情報を希望される方はこちらからご登録ください
キャリア登録 | アクセンチュア (accenture.com)
 
該当部門のカジュアル面談ご希望の方はこちらからご登録ください。
カジュアル面談お申込みフォーム