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

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

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

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

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

Screen Shot 2020-12-11 at 2.01.48 PM

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

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

一元化がもたらす障害

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

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

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

Screen Shot 2020-12-11 at 2.00.53 PM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Screen Shot 2020-12-11 at 1.59.43 PM

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

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

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

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

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

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

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

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

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

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

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

Andrew Betts
Web Developer Principal Developer Advocate
投稿日
興味がおありですか?
エキスパートへのお問い合わせ
この投稿を共有する
Andrew Betts
Web Developer Principal Developer Advocate

Andrew Betts Fastly Web Developer Principal Developer Advocate として世界各地の開発者と協力し、Web 高速化、セキュリティ、信頼性、使いやすさの向上に努めています。Fastly 入社前は、Web コンサルティング会社 (後に Financial Times により買収) 設立し、Financial Times 先駆的な HTML5 ベースの Web アプリケーションの開発を統括したほか、同紙のラボ部門の設立にも携わりました。また、W3C Technical Architecture Group (World Wide Web 開発を導く9名で構成される委員会) 選出メンバーでもあります。