ブログ

デジタル変革に関する驚くべき真実: コンテナの混乱

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2018年6月25日公開

これは、デジタル変革から生じる課題に関するシリーズの最後のブログです。

 

コンテナの混乱。

コンテナとそれを（楽々と）管理するオーケストレーションの主な目的の 1 つは、効率的なスケーリングです。 コンテナを採用する選択を促す、主に開発指向の利点は他にもありますが、NetOps の観点からは、規模とセキュリティ (の欠如) が重要です。

従来の配信アーキテクチャはコンテナ環境内では機能しません。 コミュニケーションは不安定で、動的で、予測不可能です。 コミュニケーションは増加し、環境は非常に不安定になります。 現時点での見た目は、10 分後どころか 2 分後にも変わることはありません。

ただし、コンテナ環境内の「アプリ」には、コア ネットワークとセキュリティ サービスを提供する必要があります。 内部に ID とアクセス制御を挿入したり、さまざまなインスタンス間で証明書を管理したりすることはできません。 アプリで SSL を終了すると、ユーザーにとってもアプリ自体にとっても悪夢になります。 ボット防御や OWASP Top Ten 保護などのアプリ セキュリティでさえ、このような不安定な環境にそれらをどのように組み込むかという問題が生じます。 さらに、コンテナ環境内のすべてのサービスをパブリック IP にマッピングするわけではありません。 環境内の操作を妨げることなくアプリケーション サービスを提供するには、安全なインバウンド パスが必要です。

幸いなことに、コンテナ環境内に複数のマイクロサービスとしてデプロイされたアプリは依然としてアプリ (API であっても) であり、コンテナ環境を混乱させることなく安全なインバウンド パスを確立する機会を提供する「アプリ固有の」エンドポイントがあります。 これにより、コンテナのソフトウェアベースのスケールに対する最新のアプローチを採用しながら、安定性とスケールの従来の原則に基づいた分岐型ネットワーク アーキテクチャが可能になります。 この 2 層アーキテクチャにより、コンテナ環境内で N-S バックボーンから E-W パスに移行するための信頼性の高い安全なエンドポイントが実現します。

2層アーキテクチャ

2 層アーキテクチャは、コンテナ化されたアプリに要求される速度とスケールをサポートしながら、必要な信頼性とセキュリティを提供します。 コンテナの混乱を制限することで、健全性を維持し、コンテナ化されたアプリに固有のエントロピーから共有インフラストラクチャを分離します。 これには、さまざまな変更を伴う生産パイプラインをサポートするという意図しない利点があります。 コンテナ化された環境ではアプリはより頻繁に変更される可能性がありますが、ID およびアクセス制御やその他のセキュリティ関連サービスに対する変更はそれほど頻繁ではない可能性があります。 更新は互いに独立して実行できるため、DevOps は「家」の南北側の NetOps に負担をかけることなく、より速いペースで作業を進めることができます。

入力ポイントはアプリ固有のポリシー (パフォーマンスと一部のセキュリティ) を管理し、残りの部分は安全な受信ネットワークの残りの部分で処理します。 これにより、レガシー アプリを提供する本番環境にコンテナを組み込むプロセスが、中断を最小限に抑えてスムーズかつ容易になります。 

2 層アーキテクチャが機能するためには、イングレスが実質的にアプリになること、または少なくとも仮想的に同等になることを覚えておくことが重要です。

コンテナの「壁」の向こう側に 100 個のマイクロサービスがあったとしても、イングレスはスケールとアクセシビリティを実現し、外部の脅威からアプリケーションを保護する戦略的な制御ポイントとなります。 イングレスを使用して、トラフィックがコンテナ世界の不安定で不確実な領域に入る前に、最も適切に処理されるサービスを適用します。

...これで、デジタル変革に関する驚くべき真実の探求は終わりです。 対処すべき問題点や障害は他にもたくさんありますが、このシリーズで取り上げた 4 つの問題、つまりクラウドの混乱、セキュリティの省略、規模の不経済、コンテナの混乱は、対処しなければならない問題の中で最も重大であると考えられます。

変更の影響を認識していれば、自動化、ソフトウェアベースのセキュリティとスケール、新しいアーキテクチャの力を活用して、新しいデータセンターにうまく移行することができます。