アプリケーションエンジニアがレスポンスやインフラの制約を気にすることなく、コーディングに集中できる環境をもたらすのが、エッジクラウドコンピューティングです。
近年のトラフィックやデバイスの増大とともに期待が高まるこの技術について理解を深めようと、エッジクラウドを提供する代表的な企業であるアカマイ・テクノロジーズ合同会社（以下、アカマイ。サービスはAkamaiと表記）との共催イベント「Qiita × Akamai Meetup」をオンラインで開催しました。
「開発者目線で斬る！Akamaiのエッジクラウドコンピューティングの可能性と事例」と題した本イベントでは、サーバーレスコンピューティングに詳しい株式会社サイダスの吉田真吾氏をゲストに招き、質疑応答を交えながら進行しました。今回はその模様をダイジェストでお伝えします。
プロフィール
取締役CTO
Web Performance Architect
Senior Product Manager
Senior Lead Engagement Manager
EdgeWorkers コンセプトセッション＆ディスカッション
日本と海外で異なる「エッジ」の定義
伊東氏によるセッションに入る前に、ウェビナーの聴講者へアンケートを実施しました。「Akamaiを知っているか？」という設問には89%が「知っている」と回答。次に「Akamaiを使ったことがあるか？」と問いかけたところ、50％が「使ったことがある」と答えました。最後に「エッジコンピューティングでどのようなソリューションの実現に興味があるか？」を複数回答可で尋ねたところ、「Webアプリにおけるエッジ処理（64%）」が最も多く、「IoT」「セキュリティ」が続きました。
この結果に吉田氏は、「実際にAkamaiを利用している企業とニーズにギャップはあるのか」という関心を抱きます。これに対し伊東氏は、「Webアプリ周りでのニーズは多いものの、IoTやセキュリティに関しては、まだまだこれから。ただし、セキュリティは近年最も伸びている分野だと感じます」と答えます。
続いて伊東氏は、アカマイのエッジサーバー上でサーバーレスのコード実行環境を提供するソリューション「EdgeWorkers」の説明に入る前に、本イベント名に「エッジ」ではなく「エッジクラウド」を用いた理由を明かします。
日本では製造業が盛んなことから、工場系での利用からエッジが広がってきた経緯があります。その背景から「エッジコンピューティング」と言うと、オンプレミスのデバイス側のテーマとして扱われることが多いため、意味を誤解されないようにイベント名を工夫したといいます。
一方、海外においては、アカマイがこれまで展開してきたコンテンツデリバリーネットワーク（CDN）のようなクラウド側の仕組みを指すことが一般的だといいます。
クラウドとエッジの違い
伊東氏はまず、クラウドとエッジの違いや現状について説明しました。
企業のデータセンターは、どんどんクラウドに移行しており、クラウドネイティブが一般的になっています。今後全てのトラフィックはクラウドに向かうでしょう。5G通信や4K映像とともに、データ量は増加。またデバイス数も、IoTの拡大などによって増えています。そしてマイクロサービス化によって、クラウドへのリクエストの数も増加しているのです。
そんな中、主要なクラウドプロバイダーは数社に限定されてきているため、1つの障害が社会的な問題に発展しかねません。そうした中央集権型であるクラウドの課題を解決するのが、分散型コンピューティングのエッジなのです。
アカマイは1つのデータセンターに集約しているわけではなく、世界中のISPやモバイルキャリアのデータセンターにサーバーを設置しています。そのため、企業が指向するマルチクラウドやマルチリージョンを幅広くカバーできるのです。
ここで吉田氏が、エッジのケイパビリティについて尋ねると、伊東氏は「大量のリクエストをエッジで折り返すことによる、オリジンのオフロードです」と説明します。
以前ならファイルのオフロードが中心でしたが、最近では計算処理のオフロードへと移ってきています。そして、IoTやAPI、Webといった様々なトラフィックが生み出されている背景から、世の中は低レイテンシーを求めています。エッジへの関心が高まり、技術としても確立されてきたタイミングで、アカマイは新しいサーバーレスのコンピューティングプラットフォームとしてEdgeWorkersを展開するに至りました。
Akamaiの大きな特徴は、35万台にも及ぶサーバー群です。1つのコードが35万台にデプロイされるため、非常に高い保守性を享受できます。
次に伊東氏は、クラウドではなくエッジで処理する利点を解説しました。
まず、最も分かりやすいのが距離の近さだと伊東氏は強調します。アカマイの場合は、35万台のサーバーを世界中に分散配置しているため、エンドユーザーは最短距離のサーバーに接続し、高速に処理結果を得ることができます。
2つ目のメリットは、サーバーの分散によりスケーラビリティを確保できることです。そして3つ目は、コンテンツのキャッシュです。
伊東氏は「一般的に、キャッシュは静的なものに限られ、動的なものはキャッシュできませんが、様々なロジックを組み合わせることで、キャッシュできる条件は緩和されます。そのロジックが、エッジコンピューティングの1つのテーマでもあるのです」と述べます。
エッジはユーザーのロジックを動かせる時代へ
ここで伊東氏は、アカマイの歴史を紹介しました。アカマイは1998年にMITのトム・レイトン教授が創業し、それ以後およそ10年区切りで大きな時代の変化を3つ経験して現在に至ります。最初の10年間は、CDNの時代です。次の10年である2010年代では、毎年新たなサービスの提供を開始しました。この時代は、アカマイ側から顧客のニーズを先取りして設計・展開したのです。
2020年に入り、アカマイはサーバーレスコンピューティングEdgeWorkersの提供を始めました。2010年代のようにアカマイが定義したサービスを利用するのではなく、顧客企業のエンジニアが書いたロジックが動く時代に入ったのです。
実はアカマイでは、2001年と2003年にも類似したコンセプトのサービスを提供していました。エッジでJavaを動かせるというもので、当時としてはかなり先進的な取り組みでしたが、時代を先取りしすぎたようで、ビジネスとしては成功しませんでした。
20年の時を経て、世間がクラウドに注目したことや新しい技術の後押しもあり、EdgeWorkersとして再び登場したのです。今回はJavaではなく、アプリケーション開発者人口の多いJavaScriptを扱える点が大きく異なります。
EdgeWorkersとは
EdgeWorkersは、サーバーレスのエッジコンピューティングプラットフォームです。サーバーレスコンピューティングはAWSのLambdaをはじめ、様々なクラウドベンダーが提供していますが、同様の処理をエッジで動かすことができます。
サーバーレスであることから、基盤の管理から解放され、JavaScriptのコードを書くだけで希望通りの処理を実行可能です。また、動かしたイベント数で課金されるため、経済的であることも特徴と言えます。
ここで吉田氏から課金体系について、分散された環境では、どのようにカウントするのかという質問がありました。EdgeWorkersではhttpのリクエストレスポンスのイベントをトリガーとしてカウントします。そのため料金を見積りやすく、将来のコストシミュレーションが容易ということもあり、すでに利用している企業からも好評だということです。そのイベントハンドラは、下図のように5つ用意されています。
こうしたパターンにおいてキャッシュを使うことができるので、無駄なリクエストがなく、さらに応答も早くなります。
EdgeWorkersの代表的な導入パターン
EdgeWorkersの代表的な導入パターンは、次の5つです。それぞれの事例を紹介していきます。
- サーバー「遅延」をエッジで解決
- クライアント「制約」をエッジで解決
- サーバー「制約」をエッジで解決
- サーバー処理をエッジで「分散」処理
- クライアント処理の「簡素」化
１．サーバー「遅延」をエッジで解決
これは、アメリカの小売業においてマイクロサービスをエッジに実装した事例です。
この小売業者では、位置情報を基にモバイルデバイスに最寄り店舗の情報を表示していました。アメリカは国土が広いため、1つのクラウドサービスだけを利用していると遅延が発生します。さらに、緯度と経度が変わるたびにリクエストが発生するため、負荷が高まり、すべての顧客にレスポンス遅延の影響が及んでしまいます。
そこでロジックをAkamaiに移行し応答することによって、500ミリ秒程度だったレスポンスを10〜50ミリ秒で返せるようになりました。このように、スピードを求めてエッジを利用するケースは、これから増えてくるのではないかと伊東氏は話します。
2．クライアント「制約」をエッジで解決
海外のバイヤーと国内の消費者をつなぐ、マーケットプレイスを展開している企業の事例です。プライバシー保護、パーソナライゼーション、アクセス過多に対する課題解決に、EdgeWorkersを使用しています。
以前は一般的に使われていたCookieが、ここ数年で規制されるようになったため、ブラウザで行っていたCookieのセットは、サーバーサイドに移行しなければならなくなりました。同社はサイバーマンデーやブラックフライデーといったキャンペーンでアクセスが集中する対策としてCDNを導入したいと思っていましたが、Cookieをサーバーサイドでセットできなくなることがネックとなっていました。
EdgeWorkersならエッジ上でJavaScriptを書くことができるため、こうした問題を解決することができます。
3．サーバー「制約」をエッジで解決
オリジンの制約によって導入できないソリューションをエッジで代替したケースです。アカマイのパートナーであるQueue-itでは、仮想待合室ソリューションを提供しています。これは、キャンペーンや予約サイトに大量のアクセスがあった場合に迂回させて、利用者に待機画面を表示し、順次トークンを照合して本来のサイトに戻すものです。
仮想待合室を導入した場合でも、まずはオリジンのサイトにアクセスすることになるため、リダイレクトのロジックを利用企業のオリジンのサーバーに組み込まなければなりません。そのため、どうしてもCMSの制約、時間的な制約、コストの制約が生じてしまい、導入を躊躇してしまう企業がありました。
そこでQueue-itは、オリジンではなくAkamaiにロジックを組み込んだ待合室の仕組みを実現しました。これならオリジンのサーバーに手を加えずに、EdgeWorkersだけで処理をさばくことが可能です。
ここで吉田氏は、Queue-itユーザー企業の手間について疑問を持ちました。これに対し伊東氏は、「ほんの少しだけ作業が必要」だと返します。Queue-itが提供するポータルサイトにIDや待ち時間のパラメータなどを入力すると、必要なJSONのフォーマットが生成されるため、それをコードに埋め込み、EdgeWorkersでバンドルするだけで実装できます。今後はKV型データベースも用意する予定であり、そこにコンフィグ情報を格納することでQueue-it と EdgeWorkers がよりシームレスに連携し、保守性の高い仕組みを実現できる見通しとのことです。
4．サーバー処理をエッジで「分散」処理
トークンの処理によって、オリジンサーバーへの集中を回避するケースです。マイクロサービスAPI化する場合は、全てにトークンを付与して処理することになります。1つのアプリやWebページだけでも大量にAPIを呼ぶことになるため、当然クラウド側の処理は重くなっています。そこで考えられるのが、トークンのバリデーションをすべてエッジ上で行って折り返す手法です。
5．クライアント処理の「簡素」化
ここまで紹介した4つが基本形だとすると、これは応用形です。例えばIoTデバイスでは、重いJavaScriptを動かすことができません。また、JavaScriptだとロジックが外部から見えてしまうため隠蔽化したいというニーズもあります。そこでAkamaiを通して複数のサービスを呼び、コンテンツを組み立てて応答を返すという用途です。
ユースケースをまとめると、エッジアプリケーションのパターンは以下の4つに集約されます。
アカマイでは、トライアルや様々なコンテンツを用意しています。伊東氏は、「ぜひこれらを活用して、Akamaiに触れてもらいたい」と呼びかけてセッションを終えました。
聴講者からの質問〜クラウドが同じ機能を持っていてもAkamaiを利用する意味とは？
伊東氏のセッションの聴講者から、多数の質問が寄せられました。その1つが、「多くのユーザーがクラウドシフトしている中、パブリッククラウドもサービスをリリースしていると思います。パブリッククラウドのユーザーが、クラウドネイティブなCDNではなく、AkamaiのCDNを使用するメリットはどんなものがあるでしょうか？」というものです。
これに対して伊東氏は、「利用者は1つのベンダーにロックインされたくないと考えており、それを避けるためにはセキュリティ面だけでも複数のサービスを使うなど、おのずとマルチクラウドになります。そのときに、各クラウドベンダーのサービスをそれぞれ利用するのではなく、クラウドの手前で集約してしまったほうがいいという考えです」とマルチクラウドであることの優位性を強調します。
APIのアクセストークンの検証も手前で行いたいというニーズも多いでしょう。Akamaiは、35万台での分散処理やエッジコンピューティングの特徴だけでなく、それ以外の様々な機能を包括していることも支持されている理由と言えます。
デモセッション1
GraphQLの弱点をEdgeWorkersで吸収
イベントの後半では2つのデモセッションを行いました。まずは伊藤氏による「Akamai EdgeWorkers ＋ GraphQLで実現するBFF（Backends For Frontends）アーキテクチャパターン」のデモが行われました。
伊藤氏は「EdgeWorkersや複数のバックエンドサービスをオーケストレーションして、どのようなサービスを作れるのか説明したい」と話し、まずはGraphQLについて簡単に解説しました。
GraphQLはAPI向けに作られたクエリ言語です。データベースにクエリを投げるようなイメージで、WebのクライアントがAPIから必要なデータを必要なだけ取り出せる仕様になっています。
データベースからデータを得たい場合、REST では複数のAPIを叩く必要があります。一方GraphQLでは、1つのエンドポイントに対して様々なクエリを投げることで、必要なデータが返ってくる仕組みになっています。
GraphQLの利便性は、モバイルを例にすると分かりやすいでしょう。iPhone向け、Android向けなど、個別のREST APIを用意するのではなく、GraphQLのエンドポイントで、多様なデバイスからのリクエストをまとめることができます。
ここで吉田氏はGraphQLの優位性を認めつつ、「GitHubのAPIのように外部向けに公開されているものをGraphQLで実装するのは性能面で怖さがあるし、RESTのほうがキャッシュしやすいのではないか」と指摘します。
これには伊藤氏も同意し、特にキャッシュの難しさは大きな課題であると説明します。キャッシュができなければオリジンで全てのリクエストをさばく必要があり、負荷、スケール、パフォーマンス面が課題となります。
この課題を、EdgeWorkersを使って解決しようというのが、このデモのテーマです。
まずは、GraphQLのエンドポイントをオリジンではなく、EdgeWorkers上に立てます。ユーザーからのリクエストやレスポンスをEdgeWorkersで一旦受け持つのです。こうすることでGraphQLのリクエストによる負荷の心配をオリジンから切り離すことができる上、高速に返せるようになります。
次に、裏側の処理について見てみましょう。既存のREST APIがある中で、GraphQLへマイグレーションし、並行運用しているケースが少なくありません。せっかくREST APIという資産があるのに、作り直すのがもったいないためです。そこでEdgeWorkersに新たなレイヤーを作り、そこから既存のREST APIを呼べば、無駄がない上にキャッシュをそのまま使うこともできます。
これには吉田氏も「自分たちが作っているAPIも早くGraphQLのレイヤーを挟んで出したいぐらい」と評価しました。
ここで伊藤氏は、簡単な３つのモックを含むサンプルコードを紹介し、ブラウザで動かしてみせました。コードはGitHubで公開されています。（takashito/ew-graphql-rest-federation）
最後に、こちらがEdgeWorkersのデプロイイメージです。EdgeWorkersのコードを作り、デプロイすると自動的に35万台に配られます。配信設定とコードは別々に展開されるので、2度目以降のデプロイはコードだけで構いません。
デモセッション2
検索ボックスのサジェストをエッジで高速化
ここからは、岡本氏による「エッジで処理する検索クエリサジェスト」のデモです。機械学習を使って、検索サイトやECサイトでの活用を想定した検索ボックスのサジェストを行います。
サジェストの負荷の高さを解決したいというモチベーションでデモを作ったと岡本氏は話します。特にECサイトや動画配信サービスの検索ボックスではサジェスト機能が重要な要素で、この精度が高ければ高いほど、ユーザーの満足度は上がります。
一方で、1文字入力するごとに待たされるようであればユーザーエクスペリエンスが悪くなってしまうため、レイテンシーを最小化する必要があります。サーバーレスの特性を生かして、この相反する要素を同時に実現できるのが今回のユースケースです。
一般的に機械学習やニューラルネットワークでは、GPUによるアクセラレーションで処理します。しかし、EdgeWorkersはGPUを積んでいません。そこで、JavaScriptだけで処理可能なニューラルネットワークのライブラリであるBrian.jsを使用して学習と推論を行っています。学習はローカルのバッチ処理で行い、EdgeWorkersでは推論のみを受け持ちます。
この改善策によって「およそ2桁ミリ秒程度で応答が返ってくることにぜひ注目してください」と岡本氏は話します。
そして、改めてエッジコンピューティングのユースケースにふさわしい処理であることを強調します。
岡本氏は、参考までにロジックをNode.jsに移植してパブリッククラウドのアメリカのバージニア州北部リージョンにデプロイして、日本から呼び出した場合のレイテンシーと比較してみました。その結果、EdgeWorkersが40〜60ミリ秒なのに対して、クラウド上で動くNode.jsは200〜330ミリ秒であり、EdgeWorkersの方が圧倒的に小さなレイテンシーで、ユーザー体験にも優れていました。
クラウド上にあるNode.jsとのやり取りは太平洋を横断しているので、ある程度遅延が発生するのは当たり前のことです。岡本氏が訴えたかったのは、世界中に張り巡らされた35万台のエッジサーバーにデプロイしているため、このような短いレイテンシーを世界中の誰もが享受できるということです。
Node.jsも、クラウドの東京リージョンにデプロイすれば、ほぼ変わらないパフォーマンスが出たかもしれません。しかし、世界中で同じユーザー体験を提供するには、世界中のリージョンにデプロイする必要があるのです。岡本氏はこのように、エッジを利用する意義を強調してデモを終えました。
このイベントを通じて、最後に伊東氏は「非常に良いディスカッションができ、私自身が非常に楽しめました」と感想を述べつつ、聴講者が途中で減ることなく最後まで参加してくれたことに感謝を表しました。2つ目のデモを紹介した岡本氏は、多くの質問が寄せられたものの、時間の関係ですべてに答えられなかったことを残念がっています。
以上を踏まえて吉田氏は、エッジコンピューティングのサーバーレスに関するユースケースや、アカマイのケイパビリティについてキャッチアップできたことを振り返り、「非常に有益な日でした」とイベントを締めくくりました。
イベントアーカイブ動画