エッジネイティブなアプリケーション設計の実現

これまでに Web アプリケーションアーキテクチャは大きな進化を遂げてきましたが、それは一元化され、直接管理されるプラットフォームでコードを実行するという概念に基づいていました。しかし今一度、設計原理を再考し、ネットワークのエッジでアプリケーションを解放すべきです。

2012年、Heroku の創始者のひとりが、Heroku または Google App Engine や DigitalOcean の App Platform を含む他のあらゆる Platform as a Service (PaaS) で簡単にアプリケーションを実行するのを可能にする原則の促進を図り、PaaS のマニフェストとも言うべき「Twelve-Factor App (SaaS を構築する12のベストプラクティス)」を提唱しました。

私にとって、これらのプラクティスの中で最も重要なのは、複数のインスタンスを同時に実行でき、任意のシャットダウンに対応し、標準のネットワークプロトコルに従って、依存する他のアプリケーションに接続できるステートレスプロセスを実装するという考えです。

また、これらの原則に従うことで、抽象化のポイントがプロセスベースから機能ベースへと移行するサーバレス環境への適応が容易になります。

サービスとしての機能の構築は、開発作業にさらに変化をもたらします。この場合、各呼び出し (Web アプリケーションでいう「リクエスト」) のランタイムや CPU 時間、メモリの制限を考慮する必要があり、ファイルシステムにアクセスできないこともよくあります。

物理サーバー、オペレーションシステム、ハイパーバイザー、コンテナエンジン、ロードバランサーなどの管理から単なる機能のプロビジョニングへの移行は、すばらしい可能性の解放を意味します。

一元化がもたらす障害

たとえ現在、機能コードをデプロイしているだけであっても、クラウドプラットフォームのほとんどで実行場所を選択しなければなりません。関連するデータストアやメッセージキューに加え、アプリケーションを運用するのに必要なその他の仮想インフラストラクチャのすべてに同じことが当てはまります。グローバルスケールでアプリケーションを運用する場合、レプリケーション、競合の解決、最終的な整合性のストラテジーなどの要因を考慮してこれらの選択を慎重に行いながら CDN またはその他の種類のリージョンのキャッシュをセットアップする必要があります。

しかし、実際に明示的かつ意図的にコードを各場所にデプロイするとなると、コストが高く、作業が面倒で、迅速な変更が難しいというデメリットがあります。

皆さんの中には、JavaScript またはクライアントアプリケーションを使用してブラウザで何らかのコードを実行し、ユーザーのクライアントデバイスの処理機能をすでに活用している方も多いと思います。では、エッジ・コンピューティング・プラットフォームで作成された中間プラットフォームと 5G の通信塔のハイパーローカルな処理機能による中間プラットフォームを導入するとどうなるでしょうか ?

これらの中間プラットフォームにはそれぞれメリットとデメリットがあります。クライアントデバイスから遠ざかるほど、システムのグローバルステートに関する全体像がより明確になりますが、各トランザクションの処理にかかる時間が長くなります。

例えば、最も低コストで大量のデータセットを格納できる場所はコアインフラですが、コストをかけずに (無料で) 処理を実行できる場所はクライアントです。しかしクライアント側では、ひとりのユーザーのシステムのステートにしかアクセスできません。エッジでは、共有するステートへのアクセスが可能かもしれませんが、全体的なグローバルステートの一貫した把握は難しいでしょう。

まとめると、以下の要因を考慮して、パイプラインでロジックを実行するのに適切な場所を判断する必要があります。

• 運用によって影響またはメリットを受けるユーザーの数

• ステートにアクセスする必要性、アクセスする必要があるステートのタイプ (グローバルまたはローカル、最新または完全である必要があるか)

• タスクを実行するのに必要な CPU またはメモリリソースの種類

• 考慮すべき規制、プライバシー、セキュリティ問題

スピードの加速に加え、コアインフラから離れる大きなメリットのひとつに、プロビジョニングの必要が無いということがあります。どこでも必要なインフラがオンデマンドでプロビジョニングされるためです。

エッジコンピューティングをアーキテクチャに取り入れる

このような考え方から派生する多くのアイデアは、今日の Web アプリケーションについての考え方とまったく異なるものではありません。

例えば、CMS を使用して出版関連のアプリケーションを運用している場合、エッジでページのテンプレートを作成することができます。その場合、エッジからコアインフラへのリクエストは、CMS データベースへの API コールとなります。

別の例として、React または Vue で構築されたシングルページアプリケーションのケースを考えてみましょう。サーバー側でレンダリングするパフォーマンス上のメリットについて知られていますが、現在のユーザーのコンテキストで、サーバー側のレンダリングをオンデマンドでエッジで実行することが可能です。

パブリック API を提供する企業の多くが、認証やレート制限、リクエスト検証、バッチ処理/非バッチ処理、キャッシュ、ルーティングを行う API ゲートウェイを使用しており、API のバックエンドの前面にすでに配置されています。それもエッジに移行できるのです !

接続されたデバイスのフリートを管理する IoT 企業の場合、ウィジェットの出力が低く、無線通信を介したアップデートが困難な場合が多いため、モニタリング可能なテレメトリを生成するようにします。その際、エッジで膨大な量のデータを受信、フィルタリング、集約し、データ分析のコアツールにデータを送信できます。

分散型モデルでエッジネイティブを実現する

これまでにエッジで可能な処理について説明してきましたが、さらに一歩先に進むためには、アプリケーション設計の基本原理を再考する必要があります。広く分散されたデータストアは分断の影響 (ノード間の接続の喪失) を受けやすく、より離れて分散されるほど、同期遅延が拡大し、切断の可能性が高まります。CAP 定理では、データストアに分断耐性が必要な場合、可用性と一貫性の両方を同時に保証することはできないとされています。

その結果、できる限り分断耐性のあるデータストアの必要性を避けるため、アプリケーションの多くがデータとロジックを一か所に保存する傾向があります。CRDT (Conflict-free Replicated Data Types) など、この問題を解決する他のソリューションもありますが、複雑で本番環境でのデプロイが困難です。

一方、エッジコンピューティングのメリットについて考えたとき、単一の完全かつ包括的なグローバルステートの全貌を把握する必要があるのは稀であることが明確になります。そこでこの必要性をソリューションから排除すると、エッジプラットフォームへのアプリケーションの移行がずっと容易になります。

これは通常、書き込みによって同じ地理的エリア内のデータが更新される必要があるユースケースで特に言えることです。デートアプリの Tinder や、Uber などのライドシェアアプリは、世界中でデータがこのようにローカルに共有されながら、グローバルステートのデータにもアクセスできる (しかしそれに依存しない) ユースケースの典型的な例です。

ユースケースによっては、コアインフラをまったく使用せずに済む場合もあります。

例えば Gmail や Pinterest、Dropbox のように、個人のデータセットにデータを格納して運用されるアプリケーションがこれに当てはまります。これらでは、ユーザーの近くに各ユーザーのプライマリデータストアを配置することでメリットが得られます。エッジクラウドプラットフォームを使用すれば、複数のクラウドで個別にストレージインスタンスをスピンアップする必要がなくなり、エッジプラットフォームでデータを管理し、必要な場所にデータを移動させることができます。

最後に、特定のリクエストまたはトランザクションの一環で、あるエッジロケーションが別のエッジロケーションと直接やりとりをするケースがあります。これには例えば、異なるエッジノードに接続されているユーザー間でチャットメッセージをリレーする場合や、複数のプレイヤーが参加するゲームセッションでゲームのアップデートをストリーミングする場合などがあります。

エッジネイティブのアプリケーション開発を促進する2つの設計原理

新しいプロジェクトのアーキテクチャを設計する際、エッジネイティブを実現するにはどうすれば良いでしょうか。ここで、ステートの管理方法に関してさらに2つの設計要因を考慮することをお勧めします。

• リモートステート : エッジネイティブのアプリケーションでは保持されたステートがリモートで管理される (ただしローカルでキャッシュされる) と仮定されます。リモートステートのローカルキャッシュを更新し、そのステートへのアップデートを非同期的に調整するプラットフォームのメカニズムを利用します。

• 単一ビューの必要なし : エッジネイティブのアプリケーションは、全体のステートに関する完全かつ最新のデータが無くても正常に機能します。

これらの設計原理を考慮することで、エッジを活用する未来に向けてアプリケーションの開発を促進することが可能になります。Fastly の Compute@Edge プラットフォームは、エッジでアプリケーションを構築するのに必要な機能を追加しながら進化を続けています。皆さんにとって役立つステート管理機能について、ぜひお聞かせください。