サーバーレス設計の鉄則〜メリットを最大限に活かす〜

はじめに

サーバーレスを進めるにあたって、既存のサーバーとの設計の違いで悩む事があると思います。
私も最初は「通常のサーバーだったら簡単にできるのに・・・」と思った事があります（特にログ周りとか）
が、これはサーバーレスアーキテクチャに慣れていないだけというのが大きいので、やっているうちにどうにかなる部分でもあります。

それよりも、サーバーレスのメリットを享受する為に守らないといけない鉄則が存在します。
なんとなく構築はしたけど運用的にこれで正しいのか・・・
こういう不安は誰もが当初は抱くものだと思います。しかし最低限の決まりを守れば、運用をスムーズにこなす事ができます。
今回はサーバーレスのメリットを挙げながら、私の経験から得たものを書いていきたいと思います。

サーバーレスサービスの分類

一口でサーバーレスと言っても、さまざまなサービスが存在します。
例えばAWSだったらlambdaやFargateなどがサーバーレスとして挙げられると思います。（ECSはEC2も内包するので厳密にはFargateのみになります）
ですがこの２つはアーキテクチャも特性も全く違います。
lambdaはトリガーとなるイベントから起動して処理が終わったらまた落ちます。また、動かす言語も決まっているものでしか動きません。
なのでWebサーバーのような用途には向かない形になります。
ちょっとしたスクリプトを実行したり、サービスのサービスの間に立って処理の受け渡しをするといった用途でしたら、サーバーよりは効率的なのではないでしょうか。
Fargateはコンテナが常に立ち上がっているので、lambdaと違って既存のサーバーに近い用途で使う事ができます。

このように特性がそれぞれ違うので、しっかりと理解して使わないと堅牢なインフラを構築する事は難しいでしょう。

サーバーレスのメリット

一番に考えられるメリットは、サーバーの管理が不要になることです。
当然と言えば当然なのですが、サービスの規模が大きくなるにつれてそのメリットは比例して大きくなっていきます。
１、２台で運用している場合にはそこまで負担にならないのですが、数十台規模になってくるとOSの管理がとっても面倒です（経験済）
セキュリティパッチあてる手間などもなく全て面倒を見てくれるのはやはり楽です。

もう一つはスケールが楽な事でしょうか。
以前Fargateでも挙げましたが、オートスケールの使いづらさを解消したのは大きいです。
とはいえ瞬時にスケールする訳ではないので、なるべくスケールアウトとスケールインのタイミングを考慮する必要があります。
このあたりは次回に詳しく書いていきます。