この記事では、2022年11月に発表されたAkamaiとMacrometaの提携の意義について解説しています。この提携がもたらす効果を把握するために、将来の分散コンピューティングシステムを構築するうえで必要な要素を、潜在的なユースケースを検討しながら議論していきます。
この記事に記載されている意見は筆者個人の見解であり、必ずしも雇用主の立場や方針を代表するものではありません
English version is also available: Fast Token Sharing Detection & Revocation: Akamai + Macrometa
はじめに
現在、多くの企業が知的財産やデジタルコンテンツを保護する手段として、ある種の「許可証」を発行する方法を採用しています。たとえば動画ストリーミングサービスのアカウント、トークン認証で保護された動画やゲームコンテンツのURL、あるいはソフトウェアのライセンスキーなどです。通常これらのアカウントやURLなどは個人に対して割り当てられますが、しばしばユーザーは家族や友人にそれらを共有してしまうことがあり、それが企業にとっては機会損失となることがあります。調査会社Parks Associatesが2019年に行った調査によると、アカウント共有を含む海賊行為が米国の動画プロバイダーに91億ドルの損失をもたらしており、そのうち約3分の1が不正に共有されたり盗まれたりしたアカウントによるものであると推定されています。また、2024年までには、その額が125億ドルに増加すると同社は予測しています。企業は視聴者やユーザーを増やすために、アカウントやライセンスキーの共有を当初は黙認していた場合もありましたが、昨今では収益を守るためにこれらの行為に厳しく対処するようになりつつあります。
- Netflix、ユーザー間の適切でないアカウント共有の取り締まりを2023年から本格的に開始か
- Parks Associates Forecasts $12.5B in Lost Revenue in 2024 due to pay-TV and OTT Piracy and Account Sharing
例えば、動画ストリーミングサービスは一時的なアクセストークンを用いて非会員からのアクセスを制限することがありますが、URL共有などの不正に対しては脆弱です。DRM(デジタル著作権管理)はより強力な保護を提供できますが、アカウント認証情報の共有に対処するのは難しいとされています。以下で紹介するアイデアは、不正に共有される情報がアクセストークン付きURLであってもアカウントの認証情報であっても適用可能ですが、説明を簡単にするためにアクセストークン付きURLに焦点を当てて話を進めます。
技術的課題とその解決策
不正視聴を防ぐために、サービス運営者は、同じアクセストークンを持つURLが複数の動画プレーヤーで再生されていることを検出する必要があります。一般に、1人のユーザーはある時点では単一のIPアドレスを持っているはずですので、複数のアクセス元IPアドレスから同じアクセストークンを使用してリクエストがあった場合、そのアクセストークンが複数人に共有されていると疑われます。
アクセストークンごとにアクセス元IPアドレスをカウントするという単純なアイデアがまず思いつきますが、これにはいくつかの問題があります。1つは、正規ユーザーであってもIPアドレスは固定的ではないことです。たとえばモバイル通信から自宅のWiFi接続に切り替わったりするなど、さまざまな理由でユーザーのIPアドレスは変わることがあります。また、ネットワーク構成によっては、ユーザーがそもそも複数のIPアドレスを持っていたり、NAT (ネットワークアドレス変換) が一定時間ごとにIPアドレスを変更したりする場合もあります。つまり、短時間に複数のIPアドレスからアクセスがあれば不正利用の兆候として検知すべきである一方で、長い期間をかけて変わっていくIPアドレスは正当なリクエストとみなす必要があるかもしれません。もう1つの問題として、大規模に運営されている動画ストリーミングサービスは大量の再生リクエストを処理する必要があり、アクセスログを記録しているデータベースで効率的に集計処理を実行するのは難しいということも挙げられます。さらに、ユーザーエクスペリエンスを最大化するために、この処理はできるだけユーザーに近いところ、エッジロケーションで実行されることが望ましいですが、エッジロケーションで正確かつ効率的に処理を実行するアプリケーションを設計・構築することは一般には難易度が高いと考えられています。
そこでこの記事では、サーバーレスエッジコンピューティングプラットフォームであるAkamaiのEdgeWorkersを使ってこの課題を解決していきます。EdgeWorkersはグローバルに分散されたエッジコンピューティングプラットフォームで、スケーラビリティとレスポンス速度の点で非常に優れた性能を発揮します。しかし、まだ一つ課題が残ります。EdgeWorkersはステートレスなプロトコルであるHTTPリクエストをトリガーとして動作するというアーキテクチャ上、EdgeWorkers自体もステートレスな設計になっており、複数のHTTPリクエストを関連付ける処理や集計処理をそれ単体で実現することができません。
一般的にステートレスなアプリケーションはエッジコンピューティングに適していると言われますが、裏を返せば適用可能なユースケースが限定されてしまうとも言えます。そこで本記事では、アクセストークンの不正共有を検知するといったようなステートフルな処理をエッジロケーションで実現するために、エッジコンピューティングとの親和性の高いグローバル分散データベースであるMacrometaを組み合わせることで、Akamai EdgeWorkersの優れたスケーラビリティと性能を活かしつつ、ステートフルアプリケーションを構築できることを実証したいと思います。
Macrometaとは何か？
Macrometaは、2017年に設立されたアメリカ・カリフォルニア州を拠点とするDBaaS (Database-as-a-Service) プロバイダーで、Global Data Networkというグローバル分散データベースを提供しています。Macrometaのアーキテクチャは、地理分散イベントソースとマテリアライズドビューエンジン、CRDT (Conflict-free Replicated Data Type) ベースのレプリケーションを組み合わせて、エッジコンピューティングに非常に適したものとなっています。この地理分散リアルタイムデータレイヤーへは、世界人口の80％が約10ms以内でアクセス可能であるとドキュメントでは謳われています。
Macrometaは、多機能でマルチモデルのデータベースであり、ドキュメントデータベース、Key-Valueストア、グラフデータベースを扱うことができます。また、Amazon DynamoDBやRedisと互換性のあるコレクションタイプも提供しており、開発者に幅広い選択肢と柔軟性を提供しています。
Macrometaのバックエンドシステムは、Akamaiクラウドコンピューティングサービス (Linode)を標準のインフラとして稼働しています。また、要望に応じて、他のクラウドプラットフォームを利用することも可能です。
Stream Workers
Macrometaの注目すべき機能の1つは、Stream Workersストリーミング処理エンジンです。このエンジンは、データベースへの書き込みをストリームとして解釈し、それらに対してさまざまな計算を実行することができます。Stream Workersは、Stream QLと呼ばれるSQLに似た言語を使用してストリーム上の操作を実行し、データの変換、エンリッチメント、フィルタリング、要約を行うことができます。
Stream Workersは入力として、Google Pub/Sub、HTTP、Kafka、MQTT、TCP、Macrometaストリームなど、さまざまなソースを扱うことができます。また、出力は入力と同じソースに加えて、Amazon S3、Java Message Serviceなど、複数の宛先の指定もできます。
Stream Workersは、強力なストリーミング処理機能に加えて、イベントストリームの集約や関連処理の実装を簡素化するための十分な機能セットを提供し、複雑なイベント処理 (CEP) ソリューションの開発を可能にします。これらの処理はサーバレスのFaaS (Function-as-a-Service) のような方法で実装され、Stream Workersのグローバルデプロイはわずか数回のクリックで完了します。Macrometaのデータは標準でグローバルに分散しているため、開発者は、分散アプリケーション開発に関連する技術的課題に直面することなく、アプリケーションを開発することができます。また、Macrometaのプラットフォームは、プライバシー法や関連規制に準拠するために、特定の場所でのみデータを保存するように制限するといった柔軟性も開発者に提供します。以下のサンプルアプリケーションは、Stream Workersの実力を知る参考になります。
不正トークン共有の迅速な検出と失効処理
この記事の冒頭に書いた動画ストリーミングサービスでの不正なアクセストークン共有の問題は、MacrometaとAkamai EdgeWorkersを組み合わせることで解決できるのではと考えました。そこで、このアイデアの実証環境として、動画ストリーミングサービスを模した『Cinemmon』というデモアプリケーションを開発しました。
このデモアプリでは、Akamaiのトークン認証機能であるAuth Token 2.0認証、サーバーレスエッジコンピューティング機能であるEdgeWorkers、そしてMacrometaを組み合わせて、動画ストリーミングサービスでの不正なアクセストークン共有を防ぎます。このデモシナリオでは、複数のクライアントが同じアクセストークンを使用していることを検出し、そのトークンを迅速に失効させ、Akamaiクラウドコンピューティングサービス (Linode)上で動いているElasticsearchとKibanaで構築された監視システム(参考)に通知します。これにより、動画コンテンツやその他のデジタル資産を不正アクセスから保護します。このソリューションは、動画ストリーミング業界だけでなく、ソフトウェアやゲームなど他の業界においても、類似のセキュリティ問題を解決するのに役立ちます。
Akamaiのエッジサーバーがリクエストを受信して行う最初のステップは、Auth Token 2.0を使用してトークンを検証することです。トークンがリクエストに含まれていない、または期限切れの場合、リクエストは拒否されます。トークンが有効と判断された場合、EdgeWorkersはMacrometa上のトークン失効リストを参照します。トークンがこの失効リストに含まれる場合、ここでもリクエストは拒否されます。ここまでのチェックを通過すると、Akamaiのエッジサーバーはリクエストを受け入れ、動画コンテンツをユーザーに返します。同時に、EdgeWorkersはトークンとユーザーのIPアドレス (このデモアプリではランダムに生成されたダミーIPアドレスを使用) をMacrometaのStream Workerに送信します。これにより、トークンが2分間のスライディングウィンドウ内で2つ以上の異なるIPアドレスから使用されているかどうかを判断します。これが真である場合、トークンが不正に共有されていると見なされ、Macrometa上のトークン失効リストに追加されます。またそれと同時にこのStream Workerは、Akamaiクラウドコンピューティングサービス (Linode)上の監視システムにHTTPで通知を送信します。このスライディングウィンドウの時間やいくつまでユニークなIPアドレスを許容するかを調整することで、誤検知を減らすことができます。
このロジックのコア部分は、以下のようにシンプルなStream Workerによって実現しています。
このデモアプリを体験する上では、ユーザーは3つの異なる役割を演じることになります。それぞれのステップで今自分がどの役割を担っているかを把握することが重要です。
- 正規ユーザー
- 非会員 (正規ユーザーからトークンを受け渡された人)
- サービス運営者
このデモアプリでは、最初に正規ユーザーとしてアリス、ボブ、キャロルから1人を選択します。この選択は、後で監視システムに誰が不正なトークン共有を行ったかを表示するときに使用されます。次に、動画のサムネイル『THE OCEAN』をクリックします。動画が選択されると、トークン付きのURLが表示されます。ここまでが、正規ユーザーとしての手順です。
次に、非会員の役割を担います。3つのWebブラウザを開き、架空の違法ストリーミングサイトにアクセスし、トークン付きのURLを再生します。最初と2番目のプレーヤーでは動画が正常に再生されますが、3番目のプレーヤーでは動画へのアクセスが拒否されます。
最後に、動画ストリーミングサービスの運営者の視点から、トークンの不正共有を分析することが重要です。監視画面で、どのトークンが違法に共有され、ブロックされたかが確認できます。
実際のアプリケーションにおいてトークンの不正共有を検出する際には、考慮すべきコーナーケースの存在によりこのデモで使われているロジックをそのまま使うことはできないかもしれません。しかしAkamaiのソリューションとMacrometaの組み合わせにより、この種の問題の最も困難な部分を解決することが容易になるということには同意いただけるのではないかと思います。
分散データベースが分散コンピューティングの未来に果たす役割
このデモアプリは、EdgeWorkersとMacrometaを組み合わせたユースケースを提示するだけでなく、Macrometaのような分散データベースが、Akamaiクラウドコンピューティングサービスの目指す分散コンピューティングの未来に果たす役割の重要性を強調することを目指しています。
Akamaiは「Edge」サイトとして既に世界135カ国で4,200を超えるロケーションにエッジサーバーを配置しており、これに加えて将来的には100以上のサイトで汎用的なコンピューティング基盤 (Infrastructure-as-a-Service) を提供することを目指しています。このコンピューティング基盤を提供するサイトのうち、大規模なデーターセンターを「Core」サイトまたは「Cloud」、中規模で地理的に分散した拠点を「Distributed(分散)」サイトと呼んでいます。この「Distributed」が生み出す低レイテンシーなレスポンス性能などをAkamaiクラウドコンピューティングの強みとしていく一方で、複数の拠点がシームレスに連携するアプリケーションを設計・実装するプロセスは開発者にとって難しいという課題があります。
Googleが効率的にワークロードを実行するために開発したKubernetesは、近年急速に普及・進化しています。しかし、データの保管と管理は依然として複雑な問題です。ステートレスアプリケーションは、需要の増加に合わせて簡単にスケールできますが、実用的なユースケースは限られています。ほとんどの場合、アプリケーションにはデータベースが必要であり、これは別途解決すべき分野です。Google Cloud SpannerやMicrosoft Azure Cosmos DBなどの惑星規模の分散データベースが広く成功を収めていますが、Macrometaは独自の強みにより、これらのマーケットリーダーと競合しうる潜在能力を持っていると考えられます。
Macrometaは、基礎となるアーキテクチャだけでなく、データとコンピューティングのシームレスな統合においてもユニークです。これは、単に新しい分散データベースの選択肢が1つ増えたということではなく、分散アプリケーションを設計するのが容易になったことを意味します。また、Cloud、Distributed、Edgeというサイト間のデータプレーンとして使用するのにも理想的です。以下の記事は、Macrometaの設計哲学を理解するのに良い記事です。
Has Macrometa Cracked the Code for Global, Real-Time Data?