はじめに
より素晴らしいユーザ体験の世界へ、今一度再ダイブしてみませんか？？
※ 本記事は引用文献を基に翻訳し、加筆・修正したものです。元記事については、私が今momentoのCommunity Adovcateとして働き、広く日本に内容を届ける機会が何回かあるので、翻訳まとめることをしております。
概要
サーバレスと聞くと、みなさん何を思い浮かべるでしょうか？
サーバの管理が不要？ 柔軟なスケーリングができること？ アジリティが保たれてる？ いろいろ思い浮かべますよね。
最近だとクラウド、例えば aws や Google Cloud、Azure、Oracle Cloud Infrastructure などを使い実際のシステム開発をしていると自然とサーバレスと謳うサービスを使っているかもしれない。
今回は、そんなサーバレスについて、思うことを書いていこうと思います。
サーバレスが目指す世界
- サーバレスが目指すべき世界というのは、ある業界に新規サービスを作成し、参入しようとする会社の参入障壁を減らすことで、彼らのイノベーションを加速させることにあります。
- ここでいう参入障壁というのは例えば、コストや複雑性、市場投入までの時間などが該当します。
- 開発者にとっては、例えばこれが、システムを構築するサーバの設定、ベンチマーク、プロビジョニング、実機トラブル、バージョンアップなどなど、たくさんありますよね？
- サーバレスはユーザが気づかないうちにサーバレス・サービスを利用していることが理想なのです。
- 例えば、AMI から EC2 インスタンスを起動した時に、そのイメージがS3から引っ張ってきて起動する。S3はサーバレスオブジェクトストアなので、これは理想系と言える使い方だと言えます。
サーバレスの考え方
単純さ
- サーバレスは、何も設定がいらず、遅延もせず、ただ動くだけの世界です。
- サーバーベースの場合だとそうはいきません。
- 例えば、インスタンスサイズ、インスタンスファミリー、インスタンス数、プロビジョニングされた容量の単位など
- これらの設定は管理するユーザに負荷としてのしかかるのです。
- まあ、ただ全てが全てサーバレスにするのは無理なので、ここは要件とのトレードオフになるかなと思います。
- ※ただ、これが重要なサーバレスの考え方で、インスタンス(仮想サーバ)などが見えた瞬間サーバレスではなくなるということですね。
素速さ
- サーバレスは、単一の API 呼び出しとシームレスなプロビジョニング体験ができます。
- つまり、特定のインスタンス(仮想サーバ)の起動を待つとか、ブートストラップするとかそんなものは存在しません。
- 例えば、S3 バケットをプロビジョニングするとき、何かクラスタが立ち上がるみたいな待ち時間が発生するでしょうか？ すぐにバケットへのリクエストを送信することができますよね。
瞬間的な伸縮性
- サーバレスの場合、インスタンス(仮想サーバ)がブートされ立ち上がるのも待つ必要はありません。すぐにデプロイ、リクエストを受けられるようになっている状態を提供することができます。
- では逆にクラウド以前の場合はどうだったのかというと、あるサービスを作るとなった時に、まずは場所を確保し、物理的なサーバを容量を見ながら注文し、その後の使用状況を見ながら容量を追加していくような運用をしていたのではないでしょうか？
デフォルトのベストプラクティス
サーバレスには、デフォルトでスケール性、セキュリティなどのベストプラクティスが組み込まれている。
しかし、例えば、非常に大きなオブジェクト（この場合、512MB）を20億もの項目から成るマップ（ハッシュマップ）に格納すると、そのマップ全体に対するクエリ（全てのキーと値を取得するHGETALLなど）が発行された場合、その操作は非常にメモリと時間を消費します。さらに、大きなオブジェクトがマップに格納されている場合、それが取り出される時点で、そのオブジェクトだけでなく全体のパフォーマンスに影響を及ぼし、Redisのインスタンスが落ちる可能性すらあります。これはただ一つのクエリによって引き起こされる問題ですが、それが重要なパス（クリティカルパス）に含まれていると、システム全体の可用性に影響を及ぼし、全てのユーザーに影響を与える可能性があります。このような問題を防ぐために、Redisなどのシステムでは様々な制約やガードレールが設けられています。
ここでサーバレスに立ち返ると、システム設計のベストプラクティスがデフォルトで組み込まれており、限界値や規模の自動調整など、これらの「ガードレール」がシステムの安定性を保つ役割を果たします。
そのため、ある程度縛りがあるように見えるサーバレスは、実際には大規模な障害やトラブルシューティングからシステムを守り、開発者が主要な機能に集中することを可能にします。
サーバレスとは言えないもの
Provisioned capacity
サーバレスは前もってプロビジョニングされたキャパシティなどはない。
サービスを利用するために前もって容量をユーザに対して求めることは好ましくありません。
そのそもプロビジョニングキャパシティは、危険なもので、例えばですが、プロビジョニングを間違えると料金が高額になってしまいますし、プロビジョニングを過小にしてしまうとシステムが停止してしまう可能性があります。
また、キャパシティのプロビジョニングをちゃんと行うには、キャパシティの管理、計測、ベンチマーキングを行わないと正しい値を設定することができないです。
俊敏性について言及されていないオートスケーリング
オートスケーリング機能をもつサービスがあった時に、インフラがオートスケーリングする時の容量を管理するというのはチューニングも複雑になりますし、そもそも管理する手間が増えます。
**また、オートスケーリングがアクセスによるスパイクの持続時間よりも長くかかる場合、即座にスケールできないことがわかります。**
キャパシティの最小限での利用
本当のサーバレスには、最小限でのキャパシティ利用的なものは存在しない。
どういうことかというと、サーバレス・サービスは、費用対効果が高く、低スケールで実行するため、ほとんどコストがかからない最小限のフットプリントを持っています。
これにより、ユーザは過剰なプロビジョニングによるコストは心配することなく利用できるのです。
では、そうではないものってどんなものでしょうか？
それは、年間数万円などの最小コストが設定されているサービスですね。
こういったユーザが利用したいときに、導入までのコストがかかるものはサーバレスではありません。
インスタンス
サーバレスの話をする中で一番重要なのは、インスタンスという存在があるかどうかです。
例えばですが、AWS のサービスである DynamoDB テーブルや S3 バケットなどは、それらを支えるためのインスタンスはたくさん存在します。
が、これらのインスタンスの存在について、ユーザは意識するというより存在そのものが見えないようになっています。つまり気にすることがないということですね。
これが本当のサーバレスなのです。
サーバーレスインスタンスというものは存在しないのです。
インスタンスの存在あると、そのインスタンスの例えば、数やサイズを支持しないといけなくなります。
つまりインスタンスが見えてしまっている、存在してしまっているものはサーバレスではないということですね。
メンテナンスウィンドウ
サーバレスには、メンテナンスウインドウというものは存在しないです。
つまり常に稼働しているのです。アップグレード、スケーリングのイベントそんなものは、ユーザが知らない世界で勝手にやってくれる。これが本当のサーバレスなのです。
いっぱい書いてあるけど、一体何がサーバレスなの？？
これはサーバレス、これは違くねと思った時に使えるのが下記のものです。
Momentoの公式ブログを見てみると下記のチェック項目に照らし合わせることで、本当のサーバレスを知ることができます。
まとめ
要は何が言いたかったかというと、世の中には開発者を便利にする本当のサーバレスサービスがあるということです。
より開発者フレンドリーな世界へ、今一度再ダイブしてみませんか？？
引用文献