デジタル トランスフォーメーションに関する驚くべき真実: クラウドカオス
これは、デジタル トランスフォーメーションから生じる課題に関するシリーズの 2 番目のブログです。
クラウドカオス。
何人かの賢いエンジニアが、このフレーズは冗長だと今まさに指摘しています。 クラウドは、結局のところ、ガバナンスの欠如と、明確に定義されたスケジュールなしにふわふわの白い深みに放り込まれたアプリのセキュリティ保護に対する自由放任主義的なアプローチにより、混沌としています。
ここで少し立ち止まって、クラウドに関連する混乱は技術的な問題ではなく、ほとんどの場合、人とプロセスの問題であるということに注目しましょう。
ただし、クラウドに関連する技術的な課題、あるいは少なくともアーキテクチャ上の課題がないということではありません。 それらのいくつかは、仮想ネットワークの複雑さに関連しています。 しかし、ほとんどは建築物です。 こうしたアーキテクチャ上の課題の 1 つは、アプリケーションごとに重点を置くクラウドの性質に大きく関係しています。
考えてみれば、パブリック クラウドとその導入モデルは、理想的なクラウドの形態 (プラトン主義者が言うところの「クラウドの形態」 ) であると考えられます。 つまり、プライベート クラウドもその原則に従い、同じ特性を示す必要があります。
つまり、API とセルフサービス プロビジョニングを意味します。 ダッシュボードと Web ベースのコンソール。 しかし、これは、純粋に単一のapplicationに焦点を当てた展開へのアーキテクチャの移行も意味します。
クラウドでは、アプリごとのアーキテクチャが標準です。 サービスは、一度に 1 つのアプリをサポートするように展開および構成され、それらのサービスを通過するユーザーからエンドポイントまでの単一のデータ パスを作成します。 これは、多数のネットワークおよびapplicationサービス インフラストラクチャが共有される従来のデータ センター ネットワーク設計とはまったく対照的です。
パブリック クラウドと同様にアプリごとに重点が置かれている DevOps およびアジャイル開発の世界では、「共有インフラストラクチャ」という概念が課題となります。
従来の共有インフラストラクチャ ネットワークにより、「ドアからアプリまでの 1 つの真のパス」が実現します。 今日の急速に変化するデジタル世界において、このアプローチから生じる課題は次のとおりです。
- インフラストラクチャ バージョンの調整。 あるアプリはアップグレードやパッチによって提供される機能を必要とする一方、別のアプリは既存のバージョンに依存する場合があります。 共有インフラストラクチャでは通常、同じシステム上でバージョンの多様性が許可されないため、あるアプリケーションを優先するために別のapplicationが妨げられる可能性があります。
- 競合する展開スケジュール。 共有リソースが影響を受けると、企業は交渉段階に入り、applicationの利害関係者が展開スケジュールの競合を解決しようとします。 このプロセスは長くなる可能性があり（常に苦痛を伴います）、スケジュールの競合のために新しいアプリやアップデートが遅れると、誰も得をしません。
- 爆発半径。 言うまでもなく、私のアプリが共有システムに障害を引き起こすと、そのシステムに依存するすべてのアプリが障害を起こします。 共有インフラストラクチャの影響範囲は大きく、IT 部門外の人々に展開パイプラインへのアクセスを拡大することを躊躇する大きな要因となっています。
- トラブルシューティング。 集約されたログを調べるのは大変です。 非常に成功している企業は、膨大なログをマイニングし、そのデータをアプリケーションごとのフローに分解する能力だけを基盤として築かれてきました。 共有システムのトラブルシューティングは複雑で時間がかかり、現代の IT にとって重要な KPI である平均解決時間に悪影響を及ぼします。
クラウドでは、通常、これらは問題になりません。 アプリは通常、独自のスケジュールで独自の環境にデプロイされ、多くの場合は異なるチームによってデプロイされるため、アプリごとに 1 つのパスがあります。
私たちの正気（とデータセンター）を守るためには、プライベート クラウドであるかどうかに関係なく、オンプレミスでこのアプローチを採用する必要があります。
共有ネットワーク サービスは引き続き提供されます。 ファイアウォール、IPS/IDS、DDoS、ユーザー検査は、applicationsに対して非常に中立的であり、企業全体に適用できます (また、適用する必要があります)。 その他すべてについては、アプリごと（必要に応じてアプリ固有）のサービスとインフラストラクチャがあります。 この論理的な分離により、ビジネスの安定性とセキュリティが維持されると同時に、アプリに近い、より不安定で不安定になりやすい環境が可能になります。 また、新しいアプリに必要な速度やサポートを必要としない従来の (レガシーおよび伝統) アプリのデータ パスも保持されます。 アプリごとのネットワークは、プライベート クラウド、複数のコンテナー クラスター、またはそれらの組み合わせである可能性があります。
これら 2 つの組み合わせにより、柔軟性と高速性を兼ね備え、より安定した回復力のあるネットワークが実現します。
ネットワークに対するアプリごとのアプローチには、最新のアプリ アーキテクチャと配信モデルを組み合わせた共有アプローチから生じる問題を軽減するだけでなく、さまざまな利点があります。
- 個別のパイプラインとスケジュール。 自分のアプリやインフラストラクチャ以外には影響がないため、準備ができたら自分のデプロイメントをスケジュールできます。 これにより、最新のデータ センターでサポートする必要があるさまざまなスケジュールを柔軟にサポートできるようになります。
- 爆発半径が制限されています。 私のデプロイメントによって専用システムがクラッシュした場合、それはすべて私の責任です。 他のアプリには影響しません。 この専用のアプリごとのデータ パスアプローチにより、すべてのシステムのログとエラー メッセージが自分と自分のapplicationに属していることを確信できるため、トラブルシューティングがさらに容易になります。
- スケールはプラットフォーム リソースに制限されません。 非常に不安定でダイナミックな世界では、次に訪問者が殺到するのはいつなのか、コンテンツが急速に広まるのか、あるいは最悪の場合、攻撃を受けるのかを知ることはほぼ不可能です。 原因が何であれ、共有システム (ハードウェアまたはソフトウェア) 上のアプリの需要が急増すると、規模はプラットフォームで利用可能なリソースに制限されます。 アプリごとのアーキテクチャを使用すると、この制約が緩和され、需要に応じて個々のコンポーネントをスケールアウトできるようになります。
- 真のインフラストラクチャをコード モデルとしてサポートします。共有システムでは、アプリごとのポリシーを含む基本構成であっても、共有構成が使用されます。 このモデルでは、インフラストラクチャをコード モデルとして実装しようとすると、特に複数のアプリを同時に更新しようとすると混乱が生じる可能性があります。 変更は警告なしに他のアプリに影響を与える可能性があり、必要なときに他のユーザーがリソースをロックしているためにコミットおよびクローンのアクションが失敗する可能性があります。 アプリごとのアーキテクチャにより、デプロイメント成果物が 1 つのアプリにのみ属し、アプリ所有者 (開発、DevOps、NetOps など) によって適切に管理できるようになります。
アプリごとのアーキテクチャでは、デジタル トランスフォーメーションから生じるすべての問題を解決できるわけではありませんが、クラウドから生じる混乱を抑えるのに大いに役立ちます。 これにより、セキュリティを標準化するだけでなく、ほとんどの企業が採用しているマルチクラウド環境をサポートする機会も増えます。
このシリーズの次の投稿では、デジタル トランスフォーメーションから生じる市場参入のプレッシャーによりセキュリティを省略している企業にどう対処するかについて詳しく説明します。