エッジの時代：私たちはいかにしてここに至ったのか

Ken Arora

コンピューティングとアプリケーションの世界に足を踏み入れたばかりの開発者やエンジニアは、最新かつ最先端の華々しいテクノロジーを通して物事を捉えがちです。しかし実際には、長年テクノロジー業界に身を置いてきたベテランにとっての幼なじみのように、そうした概念や類似の実装は以前から存在していることが少なくありません。基盤となる実装上の制約やインフラとの関係において、ビジネス要件と経済性が一致したり乖離したりするにつれ、それらは時代とともに注目を集めたり、下火になったりするだけです。実際、絶えず変化するビジネス環境がニーズや要件を生み出し、その結果、特定のテクノロジー戦略が再発見されたり、脇に追いやられたりします。

こうした流れを踏まえ、今後数回の記事では、より広範に分散したアプリケーションデリバリーファブリックへの進化や、エッジが担う新たな役割を背景に、今後数年で台頭するアプリケーション関連技術をいくつか取り上げます。その前に、まずは現在の状況に至った経緯と理由を振り返ってみましょう。

ステージ1：データセンターの時代

まず、約20年前にさかのぼってみましょう。当時、ビジネスサービスは、自社で所有・運用するデータセンターからデジタルで提供されていました（当時は「アプリケーション」という言葉はまだ一般的ではありませんでした）。この技術戦略は、当時としては十分かつ適切なものでした。その主な理由は、「デジタル化」されていたのが、ビジネス上最も重要な業務に限られていたためです。当時のデジタルビジネス業務の例として、次のようなものが挙げられます。

• オンライン小売業者が「デジタル化」するのは、顧客のショッピング体験と、場合によっては在庫管理に限られていました。
• 航空会社であれば、予約システムと決済システムを「デジタル化」するだけです。
• 政府は、納税など、価値の高い取引ワークフローのみを「デジタル化」するでしょう。

当時、デジタルで提供されていたビジネスワークフローは、ごく少数の最重要なものに限られていました。また、それらは、組織とITインフラを一元管理し、垂直統合された人員が地理的に同じ場所で働くという、当時の典型的な企業組織を前提としていました。そのため、組織面でも、中央で所有しIT部門が管理するデータセンターに、主に、またはすべて社内で開発されたモノリシックな「アプリケーション」を配置する形が採られたのは自然なことでした。インフラ、セキュリティ、アプリケーション（旧称「ビジネスサービス」）は、単一の垂直統合型スタックを構成していました。つまり、中央集約型かつモノリシックなテクノロジースタックは、まさに組織構造とビジネス構造を模したものだったのです。

ステージ2：クラウド時代

アプリケーションとそのテクノロジースタックの進化は、「デジタル化」が二次的な業務ワークフローにまで広がったことで、次の段階へと進みました。この段階では、デジタルワークフローの対象が顧客向けのものだけでなく、組織内部の業務ワークフローにまで拡大しました。顧客向けワークフローは、アプリストアでのアプリの急増に見られるようにコモディティ化も進みました。一方、組織内部の業務ワークフローへの拡大は、一般に企業のデジタルトランスフォーメーションという潮流の一環とされています。

その結果、企業は事業運営戦略の見直しを迫られました。特に、事業規模が急速に変化するという課題を背景に、コスト効率と俊敏性がこれまで以上に重視されるようになりました。そのため、想定される高負荷に備えて事前に料金を支払い、リソースをプロビジョニングする方式ではなく、実際の使用量に応じて料金を支払う従量課金モデルへと移行が進みました。財務用語で言えば、アプリケーションインフラへの資金投入モデルは、先行投資型のCapExモデルから、使用量に応じて支払うOpEx戦略へと次第に移行しました。同じ時期には、コスト効率と俊敏性に関連するもう1つの傾向として、従業員の地理的な分散が進み、従来以上に広範囲で信頼性の高い24時間365日の接続環境が求められるようになりました。

これらの要件、すなわち、より多くのビジネスワークフローのデジタル化、OpExコストモデルがもたらす柔軟性への期待、グローバルな24時間365日の接続性に対する要件が相まって、従量課金で利用できる、極めて大規模で高可用性を備えた仮想データセンターのグローバルネットワークが生まれる土壌が自然に整いました。こうして、パブリッククラウドが誕生しました。

さらに、パブリッククラウドの基盤が整うと、自己強化型の好循環が生まれました。パブリッククラウドがアプリケーションプラットフォームとして成熟するにつれ、従来は企業のIT部門が管理していた下位レイヤーのネットワークインフラの多くを取り込むようになりました。その結果、多くの企業でネットワーク運用チームの担当範囲が縮小し、代わってアプリケーションのデプロイとデリバリー（別名「DevOps」）およびアプリケーションセキュリティ（別名「SecOps」）に重点が移りました。もちろん、これはすべての組織に当てはまるわけではありません。サービスプロバイダーや大企業には、最も重要または機密性の高いワークフローについて、NetOpsを社内で行う必要性と能力がありました。

この流れはクラウド時代の第1段階を象徴するものでした。この段階では、パブリッククラウドは、時間とリソースを共有する外部委託型データセンターの一形態と捉えることができました。つまり、パブリッククラウドはInfrastructure-as-a-Service（IaaS）として抽象化されていました。

クラウド時代の次のフェーズは、新たに生まれた2つの異なるビジネス上の洞察によって推進されました。いずれも、フェーズ1のIaaSパラダイムを前提としていました。そのうち最初の洞察は、ビジネス価値の提供を、デジタルワークフローを実現する実装から切り離せるようになったことで得られたものです。より具体的には、企業は、パブリッククラウドがサービスとして管理するようになったテクノロジーインフラストラクチャの下位レイヤーを、企業の価値提案や競争上の差別化要因といったビジネスリーダーの主要な関心事から切り離す実行戦略を構想できるようになりました。

2つ目のビジネス上の気づきは、従来のワークフローのデジタル化と自動化が進むにつれて、上位のビジネスプロセスをはるかに短い時間単位で調整し、最適化できるようになったことです。別の記事では、この効果についてさらに詳しく説明しています。具体的には、デジタルワークフローが単純なタスクの自動化からデジタル最適化（別名「デジタル拡張」）へと進化し、最終的にAI-Assisted Business Augmentationsに至る過程を解説しています。この傾向の例として、価格調整、従業員の勤務時間のスケジューリング、在庫管理など、多岐にわたるワークフローが迅速な適応性の恩恵を受けるようになり、「ビジネスアジリティ」という言葉が生まれました。

この2つの洞察をきっかけに、企業は自社の中核的な能力ではない領域を外部委託した方が、多くの場合、コスト効率に優れることに気付きました。その結果、企業と提携するクラウドプロバイダーの双方が、パブリッククラウドで提供するサービスのさらなる高度化を目指す、互いにメリットのあるビジネス関係が生まれました。これにより、企業は技術面の負担をさらに軽減できるようになりました。その後、この考え方はパブリッククラウドによって拡張され、データベース、ファイルシステム、APIゲートウェイ、サーバーレスコンピューティングプラットフォームなど、より高度なプラットフォーム機能もパブリッククラウド上のサービスとして利用できるようになりました。さらに、パブリッククラウドプロバイダーは、主にパフォーマンス管理やセキュリティの分野で、オーバー・ザ・トップサービスの統合も提供しました。

その結果、クラウド時代がフェーズ1のIaaSモデルを越えて成熟するにつれ、Platform-as-a-Service（PaaS）とSoftware-as-a-Service（SaaS）というクラウドフェーズ2のパラダイムが登場しました。クラウドフェーズ2では、アプリケーションの稼働に必要なインフラストラクチャの大部分、場合によってはすべてを、企業からクラウドプロバイダーにアウトソーシングできるようになりました。クラウドプロバイダーは、インフラストラクチャを大規模に最適化し、より多くの専門家を投入して、広く必要とされる各種アプリケーションサービスに注力できます。これにより、企業はテクノロジー予算を中核的なビジネスロジックに集中できるようになった一方で、企業側から見れば、特定のクラウドベンダーへの「ロックイン」という望ましくない副作用が生じることも少なくありませんでした。この影響を軽減するため、企業は特にAPIとコンピューティングモデルという主要領域で、ベンダーに依存しないテクノロジーを使用して自社の中核的なビジネス価値を定義し、コード化することに努めました。その実装にはRESTおよびgRPC APIテクノロジーが使用され、仮想化およびコンテナ化されたコンピューティングモデルであるKubernetesが基盤として採用されました。

ステージ3：物理的なモノとプロセスのデジタル化

「アプリケーション」の進化における第3段階は、現在まさに台頭しつつあります。その原動力となっているのは、普段はワークフローとして意識することのない日常的な活動のデジタル化です。主にビジネスプロセスと一部の取引型消費者ワークフローがオンライン化された第1、第2段階とは異なり、この段階では、日常の「人間らしい生活」における行動に広く行き渡り、シームレスに溶け込むデジタル体験を創出します。ユースケースの全容はまだ明らかになっていませんが、拡張現実、自動化された家庭用監視システム、電力網レベルの電力管理などのテクノロジーを活用する新たなユースケースから、豊かで多面的な未来への道筋がすでに垣間見えます。こうしたソリューションは、自動運転車、デジタルアシスタント、カメラ、さまざまなスマート家電などのスマートデバイスを利用し、現実の物理世界と直接関わる点が大きな特徴です。

ビジネスの観点では、この次の移行において、デジタル消費者のユーザーエクスペリエンスがこれまで以上に重視されます。ユーザーエクスペリエンスへの注力に加え、デジタルプロセスの直接的な顧客の大半を人間ではなくデバイスが占めるようになることから、デジタル消費者のユーザーエクスペリエンス要件は、デジタル進化のこれまでの段階よりもはるかに多様になります。Stage 2からStage 3への次の移行は、前回の移行（Stage 1からStage 2）とは異なります。具体的には、通常のデジタルエクスペリエンス指標を単純に延長する（つまり「高速化し、レイテンシを低減する」）のではありません。「アプリケーション」がアプリケーションデリバリにおけるトレードオフを判断する際の選択肢を大幅に広げ、対象となるユースケースに応じて、デジタル消費者の要件に合わせたエクスペリエンスを提供できるようにすることが重要になります。

技術者の観点では、このビジネス要件が意味するのは、利用体験に対する要件が多様化するにつれ、一般的なアプリケーションデリバリ指標であるレイテンシ、帯域幅、信頼性、可用性について、トレードオフを図り、要件を指定し、最適化するための柔軟で適応性の高い手段が必要になるということです。たとえば、拡張現実の体験を提供するシステムでは、非常に低いレイテンシと広い帯域幅が求められる一方、ネットワークトラフィックのごく一部が失われても許容できる場合があります。これに対し、警報システムに使用する家庭用カメラでは、広い帯域幅が必要でも、数秒程度の比較的長いレイテンシを許容できる場合があります。スマートメーターでは、長いレイテンシと狭い帯域幅の両方を許容できる一方、すべてのエネルギー使用量を記録するため、適時性は必須でないとしても、最終的に高い信頼性が求められる場合があります。

「デジタル化」の次の段階におけるニーズに対応できる、十分に柔軟で適応性の高いシステムを設計し、アーキテクチャを構築するには、デジタル体験の提供を構成する多数のコンポーネントを、アプリケーション配信経路上のさまざまな場所に容易に分散し、必要に応じて移行できる仕組みが必要です。これらのアプリケーションコンポーネントは、ユーザー体験の要件に基づく配信ニーズ（レイテンシ、帯域幅、信頼性）に合わせて配置する必要があり、環境や負荷の変化に応じてシステムを継続的に適応させる必要があります。さらに、アプリケーションコンポーネントがアプリケーション配信経路上を移動しても、アプリケーションのセキュリティ要件（アイデンティティ管理、マルウェア対策、侵害検知）がシームレスに追随する必要があります。

未来への道を切り拓く

では、現在の状況を踏まえると、これは具体的に何を意味するのでしょうか。つまり、次のとおりです。

• まず、デジタルエクスペリエンスの利用主体の大半が他のアプリケーションやデジタルサービスになるため、APIとAPI管理の役割はこれまで以上に重要になります。
• 第2に、現在のアプリケーション配信拠点であるデータセンター、クラウド、クラウド配信型サービスだけでは、将来のニーズに十分対応できません。より具体的には、より充実した顧客体験を提供するため、インテリジェントエッジ、配信経路上のコンテンツサービスやコンピューティングサービス、配信経路内のSDWANなどのテクノロジーを活用し、デジタルアプリケーション体験の一部をエンドユーザーのより近くで提供できるようにする必要があります。さらに、クライアント側のサンドボックス技術を利用するために、アプリケーション配信経路を拡張する必要が生じる可能性もあります。
• 第3に、エッジはデジタルエクスペリエンス配信への「入口」としての役割をますます担うようになり、その結果、配信をオーケストレーションする主要なポイントとして、さらに重要性が高まります。
• 最後に、セキュリティは本質的かつ広範に組み込まれている必要があるだけでなく、アプリケーション配信経路上でアプリケーションコンポーネントがどのように分散しているかに左右されないものでなければなりません。

この最後の3つのトピックについては、本シリーズの次回以降の記事で取り上げます。まず「エッジ」とその今後の方向性について、続いて、場所にまったく依存しないセキュリティの考え方とはどのようなものかを解説します。

著者について

Ken Arora

Ken Aroraのその他のブログ記事