開発者向けプラットフォームを提供するUnkey社は、API認証サービスを全面的に再構築したことを明らかにした。同社は、サーバーレスアーキテクチャであるCloudflare Workersから、状態を保持するGoサーバーへ移行した。この決定は、サーバーレスアーキテクチャの制約を再評価した結果によるものであるという。同社によれば、この移行によりパフォーマンスが6倍向上し、エンジニアリング作業の大部分を占めていたワークアラウンドが不要になったと述べている。
Unkey社の共同創業者であるAndreas Thomas氏は、今回の決定について「遅延が問題だった」と説明した。Thomas氏によれば、数千のアプリケーションのリクエスト経路にサービスが存在する場合、「すべてのミリ秒が重要になる」という。Unkey社は問題の根本がキャッシュにあることを突き止めた。Cloudflare社のキャッシュは99パーセンタイルで30ミリ秒以上を要しており、目標としていた総応答時間10ミリ秒未満を達成するには十分な速さではなかったという。
サーバーレス関数は設計上ステートレスであり、起動してリクエストを処理した後、消滅する仕組みになっている。そのため、キャッシュされたデータは別の場所に保存され、ネットワークを介して取得する必要がある。Unkey社はこの課題に対処するため、Cloudflare社の各種サービスを活用したマルチティアキャッシングシステムの構築を含む、さまざまな対策を試みた。キャッシュキーの最適化や有効期限の調整も行ったが、状況の物理的な制約を克服することはできなかった。トーマス氏は「ネットワークリクエストがゼロである場合、1回のリクエストよりも常に速い」と簡潔に述べた。どれほど巧妙なキャッシングを行っても、ステートフルなサーバーがデフォルトで行う「ホットデータをメモリに保持する」という動作には及ばなかったという。
Unkey社は、分析やログ記録のためにサーバーレス機能からイベントデータを抽出する必要があった。通常のサーバーにおける典型的な設計パターンでは、イベントをメモリ内でバッチ処理し、数秒ごとにまとめて書き出す方法が一般的である。しかし、サーバーレス環境では、機能が終了した瞬間に消滅する可能性があるため、呼び出しのたびにデータを書き出す必要があった。
この課題に対応するため、Unkey社は「chproxy」と呼ばれるカスタムのGoプロキシを構築した。このプロキシは、分析イベントを一時的にバッファリングし、分析サービス「ClickHouse」に送信する役割を果たす。ClickHouseは小規模な挿入が多数発生するとパフォーマンスが低下するため、この対策が必要だった。また、同社はメトリクスやログ用に別のパイプラインも構築した。このパイプラインでは、中間的なCloudflare社の「Workers」を経由させ、イベントを解析・分割した上で次の処理に送る仕組みを採用した。
Unkey社は、Durable Objects、Logstreams、Queues、Workflows、さらにいくつかのカスタムステートフルサービスを利用していたことが判明した。トーマス氏によれば、チームは新しいSaaS製品の評価や統合に多くの時間を費やしており、顧客の課題ではなく、サーバーレスアーキテクチャが生み出した問題を解決していたという。新たなシステムはAWS Fargate上で稼働し、Global Acceleratorをフロントに配置している。このシステムは引き続きトラフィックをグローバルに分散させるが、長時間稼働するGoプロセスがデータをメモリに保持し、イベントを自然にバッチ処理できるようになった。トーマス氏は、サーバーレスアーキテクチャを支える補助的なサービスが不要になったことで、コードが簡素化され、Unkey社のコストも削減されたと説明している。
「ネットワークリクエストがゼロである場合、1回のリクエストよりも常に速いです。どれだけ外部キャッシュを積み重ねても、この根本的な制約を克服することはできません。」 — Andreas Thomas氏（Unkey社共同創業者）
Thomas氏は、Cloudflare社の「Workers」サービス自体が安定しており、プラットフォームが広告通りに機能していることを強調した。一方で、問題はトーマス氏が「ステートレス性を補うために発生する“複雑性のコスト”」と呼ぶ点にあった。Unkey社は、通常のステートフルなアプリケーションであれば標準的に提供される機能を再現するためのインフラを構築し、維持しなければならなかった。
この変更により、これまで利用できなかった機能が利用可能になった。Cloudflare社の「Workers」を使用した場合、Unkey社の顧客にとってセルフホスティングはほぼ不可能だった。サーバーレスランタイムは理論上オープンソースであるものの、ローカル環境での実行は容易ではない。しかし、モノリシックなGoアプリケーションを採用したことで、Unkey社の顧客は単一のDockerコマンドで製品を起動できるようになり、操作が簡単になるだけでなく、企業が求める厳格なデータレジデンシー要件にも対応可能な柔軟性を備えることとなった。さらに、エンジニアはノートパソコン上で数秒で全スタックを実行できるようになり、Cloudflare社特有のAPIを回避する必要がなくなったことで、ローカル開発が容易になった。Unkey社は来年、顧客がサービスを任意の場所で実行できるデプロイメントプラットフォームを立ち上げる予定であり、これにより製品のポータビリティと簡便性が新たな売りとなる見込みである。
この転換は、他の著名な企業がサーバーレスコンピューティングが要求の厳しい本番環境でその約束を果たしているかどうかを疑問視している時期に行われた。注目すべき移行例として、Amazon社の「Prime Video」は、分散型のサーバーレスシステムから単一プロセスへと動画品質モニタリングを統合し、インフラコストを90%以上削減した。この事例は、サーバーレス製品「AWS Lambda」を通じてマイクロサービスを普及させたAmazon社自身によるものであることから、大きな話題を呼んだ。このアーキテクチャは多くの点でUnkey社のものと類似しており、大量のワークロードとコンポーネント間の緊密な連携が求められる構造であった。サービスの規模が拡大するにつれ、サーバーレスの「呼び出しごとの課金」モデルは経済的に合理性を失い、ステートレスなアーキテクチャが単純な操作を過度に複雑化させる結果となった。
LinkedIn上で、サーバーレスコンサルタントのYan Cui氏はUnkey社の発表に対し、「サーバーレスが役立たなくなるのはいつか」という問いを投げかけ、初期成長に適したアーキテクチャが後に制約となる可能性を指摘した。Unkey社の場合、Cloudflare社の「Workers」プラットフォームに固有のキャッシュやレイテンシーの限界に直面したという。エンジニアのLuca Maraschi氏はさらに率直に、チームはトラフィックパターンを慎重に検討し、エッジやサーバーレス機能がすべてのワークロードに最適であると安易に考えるべきではないと述べた。一方で、コミュニティ内の意見には同情的なものもあり、Ten10社のDevOpsコンサルタントであるMax Hayward氏は、分散型アーキテクチャを構築する内部的な圧力があったことを認めつつ、振り返ればより単純なアプローチの方が適切だったと述べた。
要約すると、Unkey社の事例は、サーバーレスが依然として有用なアーキテクチャパターンであることを示している。特に、イベント駆動型や断続的なワークロードに対しては効果的であり、永続的な状態を維持する必要がないスパイク型のトラフィックを持つサービスでは、コスト削減の大きな効果が期待できる。しかし、Unkey社やAmazon社の「Prime Video」の経験から、ステートレスモデルは高スループットかつ厳格なレイテンシー要件を持つサービスには必ずしも最適ではないことが示唆されている。