デジタルトランスフォーメーションの意外な真実：クラウドの混沌

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

デジタルトランスフォーメーションに伴う課題を取り上げるブログシリーズの第2回です。

• デジタルトランスフォーメーションに関する意外な真実

クラウドの混沌。

今まさに、ある聡明なエンジニアが「この表現は重言だ」と指摘していることでしょう。結局のところ、クラウドはカオスそのものです。ガバナンスが欠如し、明確なスケジュールもないまま、そのふわふわとした白い奥深くへ放り込まれたアプリのセキュリティ確保も成り行き任せなのですから。

ここで、クラウドに伴う混乱の多くは、技術ではなく、人とプロセスの問題であることを確認しておきましょう。

だからといって、クラウドに技術上の課題、少なくともアーキテクチャ上の課題がないわけではありません。その一部は、仮想ネットワークの複雑さに起因します。しかし、その大半はアーキテクチャ上の課題です。その1つは、アプリケーション単位に重点を置くという、クラウドの本質そのものに関係しています。

考えてみれば、パブリッククラウドとその導入モデルは、クラウドの理想形（プラトン主義者が言うところの「クラウドのイデア」）と見なされています。つまり、プライベートクラウドもその原則に従い、同じ特性を備えるべきです。

つまり、APIとセルフサービス型のプロビジョニング、ダッシュボードとWebベースのコンソールが必要です。しかし、それだけでなく、単一のアプリケーションに特化したデプロイメントへとアーキテクチャを移行することも意味します。

クラウドでは、アプリケーション単位のアーキテクチャが一般的です。サービスは一度に1つのアプリケーションをサポートするように導入、構成され、ユーザーからエンドポイントまで、それらのサービスを経由する単一のデータパスを形成します。これは、多数のネットワークおよびアプリケーションサービスのインフラストラクチャを共有する従来のデータセンターネットワーク設計とは大きく異なります。

パブリッククラウドと同様にアプリ単位を重視するDevOpsとアジャイル開発の世界では、「共有インフラストラクチャ」という考え方が課題となります。

従来型の共有インフラストラクチャとネットワークでは、「入口からアプリまでの唯一の経路」が形成されます。変化の速い今日のデジタル世界において、このアプローチから生じる課題は次のとおりです。

• インフラストラクチャのバージョン調整 あるアプリではアップグレードやパッチで提供される機能が必要な一方、別のアプリでは既存バージョンへの依存が生じる場合があります。一般に、共有インフラストラクチャでは同一システム上で複数のバージョンを使用できないため、一方のアプリを優先することで、もう一方のアプリに支障をきたす可能性があります。
• 競合するデプロイスケジュール 共有リソースに影響が及ぶと、企業ではアプリケーションの関係者がデプロイスケジュールの競合を解消するための調整に入ります。このプロセスは長期化することがあり（しかも常に困難を伴います）、スケジュールの競合によって新しいアプリケーションやアップデートの提供が遅れれば、誰にとってもメリットはありません。
• 影響範囲。言うまでもなく、あるアプリが原因で共有システムに障害が発生すると、そのシステムに依存するすべてのアプリが停止します。共有インフラの障害による影響範囲は非常に広く、IT部門以外の担当者にデプロイパイプラインへのアクセスを拡大することがためらわれる大きな要因となっています。
• トラブルシューティング。 集約されたログをくまなく調べるのは大変です。膨大なログを分析し、データをアプリケーションごとのフローに分解する機能だけで、大きな成功を収めた企業もあります。共有システムのトラブルシューティングは複雑で時間がかかるため、現代のITにおける重要なKPIである平均解決時間に悪影響を及ぼします。

クラウドでは通常、こうした問題は発生しません。一般に、アプリはそれぞれ独自の環境に個別のスケジュールでデプロイされ、多くの場合は異なるチームが担当するため、アプリごとに1つのパスが確保されます。

私たち自身（そしてデータセンター）を守るため、プライベートクラウドかどうかにかかわらず、オンプレミスでもこのアプローチを採用する必要があります。

共有ネットワークサービスは引き続き必要です。ファイアウォール、IPS/IDS、DDoS対策、ユーザー検査はアプリケーションに依存しないため、全社規模で適用できます（また、適用すべきです）。それ以外については、アプリケーション単位（必要に応じて「アプリケーション固有」と呼ぶこともできます）のサービスとインフラストラクチャを用意します。このように論理的に分離することで、ビジネスの安定性とセキュリティを維持しながら、アプリケーションに近い、変化が激しく不安定になり得る環境にも対応できます。また、新しいアプリケーションに必要な速度やサポートを必要としない従来型（レガシーおよび長年使用されている）アプリケーション向けのデータパスも維持できます。アプリケーション単位のネットワークには、プライベートクラウド、複数のコンテナクラスター、またはその組み合わせを使用できます。

この2つを組み合わせることで、安定性とレジリエンスが向上し、柔軟かつ高速なネットワークを実現できます。

アプリ単位のネットワークアプローチには、最新のアプリケーションアーキテクチャやデリバリーモデルと共有型アプローチを組み合わせることで生じる問題を軽減できるだけでなく、さまざまなメリットがあります。

• 個別のパイプラインとスケジュール。自分のデプロイが影響するのは自分が担当するアプリとインフラストラクチャだけなので、準備が整い次第、自分でデプロイのスケジュールを設定できます。これにより、最新のデータセンターで対応が求められる多様なスケジュールにも柔軟に対応できます。
• 影響範囲の限定。専用システムへのデプロイによってクラッシュが発生しても、その影響は自分だけにとどまり、他のアプリには及びません。また、アプリごとに専用のデータパスを使用するこのアプローチでは、すべてのシステム上のログやエラーメッセージが自分と自分のアプリに関するものだと判断できるため、トラブルシューティングも容易になります。
• スケーリングはプラットフォームのリソースに制限されません。変化が激しく動的な環境では、次にアクセスが殺到するタイミングや、コンテンツが急速に拡散するかどうか、さらには攻撃を受けるかどうかを予測することは、ほぼ不可能です。原因が何であれ、共有システム（ハードウェアまたはソフトウェア）上のアプリへの需要が急増すると、スケーリングはプラットフォームで利用可能なリソースに制限されます。アプリ単位のアーキテクチャを使用することで、この制約を緩和し、需要に応じて個々のコンポーネントをスケールアウトできます。
• 真のInfrastructure as Codeモデルをサポートします。共有システムでは、アプリごとのポリシーを含む基本設定だけの場合でも、設定が共有されます。このモデルでは、Infrastructure as Codeモデルを実装しようとすると混乱が生じる可能性があります。特に、複数のアプリが同時に更新を試みる場合は顕著です。変更が予告なく他のアプリに影響したり、必要なリソースが他のユーザーによってロックされ、コミットやクローン操作が失敗したりすることがあります。アプリごとのアーキテクチャでは、デプロイメントアーティファクトが1つのアプリにのみ属することが保証され、アプリの所有者（開発、DevOps、NetOpsなど）が適切に管理できます。

アプリ単位のアーキテクチャですべてのデジタルトランスフォーメーションの課題を解決できるわけではありませんが、クラウドによる混乱の抑制には大きく貢献します。また、セキュリティの標準化を進めやすくなるほか、多くの企業が移行しつつあるマルチクラウド環境にも対応できます。

このシリーズの次回記事では、デジタルトランスフォーメーションに伴う市場投入へのプレッシャーからセキュリティ対策を省略してしまうケースへの対処方法を詳しく解説します。ぜひご期待ください。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事