CNDT2020シリーズ：サーバーレスの現状と実装の苦労をメルカリのSREが語る

CloudNative Days Tokyo 2020では、ベンダーだけではなく多くのエンドユーザーによるセッションも実施された。このような場合、失敗談を含めてエンドユーザーならではの実体験がベンダーによる宣伝よりもヒントになることは往々にして起こり得る。今回の記事ではメルカリのSite Reliability Engineerである山下慶将（けいすけ）氏のセッションを紹介する。

参考リンク：Serverlessを取り巻く現状とAll Serverlessでプロダクトを構築する苦労

タイトルは「Serverlessを取り巻く現状とAll Serverlessでプロダクトを構築する苦労」というもので、後半にはメルカリで実際にサーバーレスで実装されたシステムに関する考察が含まれている。

サーバーレスの最新の状況

サーバーレスを解説するメルカリの山下氏のセッション

前半はサーバーレスの現状をサービスと製品・関連製品に分けて解説する内容で、サーバーレスが今も進化をしていることを解説した。

サーバーレスと関連製品を分けて解説

メルカリの視点では、主にパブリッククラウドのサービスとして提供されているサーバーレスにフォーカスしているようで、ここではGCP、AWS、Azureなどが提供しているサーバーレスを主に考察している。その中でも特にCloudFlareが提供するCloudFlare Workersを紹介している。

Cold Startがないサーバーレス、CloudFlare Workers

サーバーレスは予め仮想マシンをブートしなくても、アプリケーションのコードをデプロイするだけでコードが実行される。無駄なCPUやメモリーを必要とせずに利用した分だけ課金されるため、トランザクション処理よりもアドホックな利用形態には最適な実行形態だが、実際にリクエストが到達してからコードが立ち上がる「コールドスタート」となるため、どうしても処理が始まるまでに遅延が生じてしまう。それをCloudFlare Workersは回避していることを解説した。

サーバーレスをCDNのエッジノードで実行することで高速化

またパブリッククラウドではリージョンを選んでコードをデプロイすることが可能だが、それをサーバーレスにも応用できるように徐々になっていることを解説した。

ここで注意が必要なのは、山下氏はあくまでもパブリッククラウドの文脈としての「エッジ」、つまりパブリッククラウドまたはCDNのエッジノードでの実行、要するにクライアントに近いリージョンに存在するサーバーでの実行を解説していることだ。IoTの文脈で言うところのエッジ端末、もしくは極小のエッジサーバーでのサーバーレスは視野に入れていないことがわかる。

サーバーレスのプラットフォームも多様化している

そしてサーバーレスのプラットフォーム自体が多様化していることを解説。パブリッククラウド、SaaSベンダー、Kubernetes上のオンプレミス、ブロックチェーンや機械学習というドメインに特化したサーバーレスのように、多くのバリエーションがあることを指摘した。

プラットフォームが多様化していることを解説

次にサーバーレス自体の製品サービスではなく、それを支えるエコシステムに属するソフトウェアについても解説を行った。ここではサーバーレスのトリガーとなるイベントソース、開発方法などについて紹介した。

開発を行うためのフレームワークを紹介

ここでもAWS、GCPなどのパブリッククラウドにおけるフレームワークを紹介している。またVercel、Dapr、Nuweba、Nimbellaなどを紹介し、3大パブリッククラウド以外にも選択肢が拡がりつつあることを紹介した。Nimbellaは元HPEのマーケティングと元IBMのエンジニアが創業したサーバーレスのベンチャー、DaprはMicrosoftが開発をリードするマイクロサービスのフレームワークだ。

Daprなどもサーバーレスの一つとして紹介

Daprについては2020年7月にMicrosoftのイベントの解説記事を公開しているので参照されたい。

参考：分散型アプリの開発と運用を分離するOAMとDapr、そしてKubernetes上の実装であるRudrとは？

また開発ワークフローの中でもCI/CDツールとの連携は必須であり、その部分についても複数のバージョンをデプロイしてスプリットできるカナリアリリースのサポートやSpinnakerとの連携なども紹介した。

CI/CDも使えるように進化するサーバーレス

またパブリッククラウド側にあるサーバーレスのコードからプライベート側にあるコードに対するアクセスも、一旦外部のインターネットに出なくてもVirtual Private Cloud（VPC）に接続できる機能を解説し、実際にインターネットサービスの中で遭遇する苦労を解説した形になった。

パブリック側とプライベート側の接続がサーバーレスでは悩みの種

同様にパブリッククラウドが用意するWeb Application Firewall（WAF）やロードバランサー、APIゲートウェイなどの利用に関しても苦労が絶えなかったと語る山下氏だが、それらも徐々に改善しているという。

ネットワークはKubernetesだけではなくサーバーレスでも問題

サーバーレスによる開発の実際

そして後半は実際にサーバーレスを使って開発したアプリケーションを解説する形でその体験を語った。

サーバーレスを使った体験談を紹介

これはWiFi Attendance System（WIAS）と呼ばれるタイムカード打刻システムで、メルカリのオフィスにあるWiFiに接続した時、もしくはSlackでコマンドを送った時に出社が打刻されるというシステムだ。メルカリでは全社員が使うシステムであるという。

サーバーレスを使って開発されたタイムカード打刻システム

当然だが、朝夕の出退勤のタイミングで打刻されるため、メッセージの量に特徴があり、それがGCPからの請求額に反映されていることが次のスライドでも見て取れる。

起動のされ方に特徴があり、サーバーレスに適しているという

ただしSlackとの連携においては、Slackへの返答が3秒を超えるとタイムアウトしてしまうという状況をどう回避するのか？という悩みがあったと説明した。

Slackへのレスポンスが3秒を超えるとタイムアウトしてしまう

これはサーバーレスのコードが起動される際にコールドスタートの状態で実行を開始する処理時間に加えて、認証などの別の処理も加わるからだ。結果として、状況は悪くなってしまったという。

コールドスタート問題の解決方法

この問題の解決のために、Node.jsの最新のランタイムの採用や処理を分けてレスポンスを返してから重い処理を行うなどの工夫をしたことを解説した。同様の問題は常駐するデーモン型であっても発生するが、サーバーレスでは特にその部分に関しては注意すべきだと実際の経験に基づいたサジェストをしていた。

またVPCとパブリッククラウド側で稼働するサーバーレスワークロードとの接続に関しても、注意が必要だと解説した。

パブリック側のサーバーレスとプライベート側をつなぐ部分の解説

そしてGitを使ったコード管理についても、「数多くのサーバーレスのコードを単一のリポジトリーで管理する発想はCircleCIとは合わなかった」として、GitHub Actionsを使ったコード管理に移行したことを説明した。

CircleCIからGitHub Actionsに移行してモノレポでの管理を容易に

ここまででパブリッククラウドにおけるサーバーレスの概況、サーバーレスを利用する際に直面した問題点の解説、そしてコールドスタート問題への対応、コード管理の方法などをまとめとして紹介した。

まとめ

現状のサーバーレスはツールやエコシステムも成熟途上の段階であり、先行するパブリッククラウドをオープンソースプロジェクトが追いかけているという状況だ。このセッションでは、パブリッククラウドでの利用に関するいくつかの重要な知見を得ることができた。