デジタルトランスフォーメーションの意外な真実:規模の不経済

F5エコシステム | 2018年6月19日

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

規模の不経済。

ビジネスが成長するにつれ、特に長期的には、対処が必要な負担が積み重なりがちです。サポート対象のアプリケーション数が減ることはほとんどありません。通常は増加し、数年のうちに指数関数的に増える場合もあります。平常時でも、アプリケーション数は4年ごとに倍増する傾向があります。新しいテクノロジーが急速に普及すると、その数はさらに増加します。

アプリが増えるたびに、運用面で必要なサポートも増えていきます(ここでいう運用とは、ネットワーク、コンピューティング、ストレージ、セキュリティのことです)。しかし、垂直スケーリングには限界があり、問題に対してハードウェアを投入し続けることはできません。人材についても同じです。アプリの増加に合わせて、運用担当者を増やし続けるわけにはいきません。そうすれば、管理のオーバーヘッドが増え、誰が何を担当しているのかを把握するだけでも苦労するようになり、その担当者と実際に話すことはおろか、コミュニケーション自体が遅くなります。

これが「デプロイ効果逓減の法則」の示すところです。運用作業が増えすぎると、かえってデプロイの妨げとなり、トレードオフが生じ始めます。悪魔と取引するファウストのように、セキュリティよりスピードを、安定性よりスケールを優先するようになります。やがて転換点を迎え、理論上の限界に達すると、開発部門、運用部門、そして事業部門は別の解決策を探し始めます。

要するに、増え続けるアプリに対応するために運用担当者を増員できるのは、「デプロイ逓減の法則」に直面するまでです。

だからこそ、増え続けるアプリケーションと、より迅速なデプロイへの要求に運用部門が対応していくには、自動化が不可欠です。どれほど速く入力しても、コンピューティングの処理速度にはかないません。

ただし、自動化は単なるスクリプト作成にとどまらないことに留意してください。

すでに多くのスクリプトを活用しており、それがデプロイ競争に何とか後れを取らずに済んでいる一因であることは確かです。しかし、自動化を真に成功させるには、デバイス単位やアプリケーション単位で実行すべきではありません。決してそうすべきではありません。その方法では拡張できないからです。デバイスやアプリごとに1つずつスクリプトを作成しているのであれば、自動化の方法が適切ではありません。

自動化では、プロセス(つまり実際にはオーケストレーションなのですが、これは私が何度挑んでも倒せない風車のようなものです)と、一貫した実行を重視する必要があります。つまり、単に変更をスクリプト化するのではなく、自動化を導入しなければなりません。そのためには、Infrastructure as Codeなど、DevOpsの原則を取り入れた新たなアプローチが必要です。

Infrastructure as Code

Infrastructure as Codeは比喩です。つまり、実際のインフラストラクチャはソフトウェアの場合もハードウェアの場合もあり、クラウド環境にもオンプレミス環境にも存在し得ます。Infrastructure as Codeの動作はAPIとデプロイメントアーティファクトを使用して実現するため、デプロイメントにおいて実装方式は重要ではありません。構成をデバイスから分離することで、デバイスをブラックボックスとして扱えます。

重要なのは、目的のサービスに合わせてデバイスをプロビジョニングし、構成するために使用するテンプレート、スクリプト、ポリシーなどのデプロイメントアーティファクトです。これらはリポジトリ(オンプレミス)に保存されます。ネットワーク、セキュリティ、ストレージ、アプリケーションインフラのいずれであっても、特定のサービスを完全に記述しており、必要に応じてサービスを再作成できます。これらのアーティファクトを使用すれば、ファイアウォールルールの追加、ロードバランサーのデプロイ、WAFの構成といった個々のタスクを自動化できます。さらに、それらをオーケストレーションされたプロセスに統合することで、継続的デプロイメントを実現できます。

これが規模の不経済への対処において重要なのは、スクリプトだけでは依然としてデバイスごとの作業になるためです。スクリプトがあれば、5分かかる作業を5秒に短縮できます。しかし、実行は依然として手動であり、プロセスを進めるには人の介在が必要です。より重要な、*プロセス*全体の自動化というニーズには対応できません。デジタル経済で競争するために必要な規模の経済を実現するには、プロセス全体の自動化が不可欠です。

本シリーズの最終回では、コンテナ化された環境にデプロイされるアプリが増え続ける中、それらを安全かつセキュアに提供する方法を詳しく解説します。ぜひご期待ください。

共有
タグ: 2018

著者について

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

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

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

関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5エコシステム | 2025/04/15

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視

F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。

F5 BIG-IPでAI防御を実現
F5エコシステム | 2024/11/13

F5 BIG-IPでAI防御を実現

F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。

F5 Advanced WAFによるGraphQL APIの保護
F5エコシステム | 2021/08/31

F5 Advanced WAFによるGraphQL APIの保護

ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。

アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
F5エコシステム | 2019/02/19

アプリケーションサービスの現状 通信業界版:リーダーとしての台頭

通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。

デジタルトランスフォーメーションは、単なるペーパーレス化ではない
F5エコシステム | 2017/07/10

デジタルトランスフォーメーションは、単なるペーパーレス化ではない

デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。

やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
F5エコシステム | 2016/09/19

やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。

もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。