サーバーレスで組織の技術・開発文化を次世代へ！自社開発へのサーバーレス導入をサーバーレスエキスパートが解説します🤔

こんにちは！

本記事では、サーバーレスが組織の技術や開発文化を次世代へ導くと考えられる、7つの理由と導入の手引を紹介します！自社開発へのサーバーレス導入を考えている方は必見です。

想定する読者

• サーバーレスについて知りたいヒト
• サーバーレスをはじめたいヒト

はじめに

マイクロサービスとモノリシックアーキテクチャーを理解しておきましょう

よくサーバーレス（マイクロアーキテクチャー）とモノリシックアーキテクチャーが比較されますが、結論どちらが優れているかは議論すべきでは有りません。自社内の開発メンバーのスキルセットや実現したい機能要件、バーストアクセス時のスケール考慮等を前提に導入を検討するべきです。

わたしたちは数多くの企業様へサーバーレス導入を行ってきましたが、企業様によってはサーバーレスの内製化に苦労していることを何度か目にしています。自社にとってモノリシックアーキテクチャー・マイクロサービスどちらが適切なのかきちんと判断する事が必要です。サーバーレスは銀の弾丸では有りません。

モノリシックアーキテクチャーのメリット・デメリット

メリット
デプロイが簡単	単一の実行可能ファイルまたはディレクトリをデプロイするだけなので、デプロイが簡単。
開発効率	アプリケーションを 1 つのコード で構築すると、開発効率が良い。
テストしやすい	単一のユニットが容易。
デバッグが簡単	すべてのコードが 1 か所に配置されているため、ワークフローを見やすくログも検出しやすい。

デメリット
開発速度の遅さ	大規模な開発時、多くのケースでコードが属人化しやすく複雑になり開発効率が低下しやすい。
スケーラビリティ	個々の機能単位でスケーリングできない。インフラでスケーラビリティを考慮する必要がある。
信頼性	どこか一箇所にエラーがあると、アプリケーション全体の可用性に影響する恐れがある。
言語/フレームワークのアップデートのしにくさ	フレームワークや言語のバージョン変更はアプリケーション全体に影響し、変更にはコストと時間を要する。
デプロイ	少しの変更でも、全体を再デプロイする必要がある。

マイクロサービスのメリット・デメリット

メリット
オートスケーリング	マイクロサービスは一定の閾値に基づき、コンピューティングリソースを自動的にデプロイ（追加）し、大量のアクセスに対応できる。
継続的デプロイ	変更箇所のみのデプロイのため、小さく変更を反映することが可能。
高い保守性とテスト性	新しい新機能を容易に試すことができる上、うまくいかない場合は即座にロールバックが可能なため、コードの変更が容易になり、新機能の市場投入までの時間を短縮できる。
高い信頼性	アプリケーション全体が停止する恐れなしに、特定のサービスまたは機能の変更のみをデプロイできる。
テクノロジーの柔軟性	例えば AWS Lambda であれば、マイクロサービスごとに自由に言語を選択可能。

デメリット
開発の無秩序	複数のヒト、チームによってより多くの変更がされるため、無秩序な増加を適切に管理しないと、かえって開発速度が遅くなる傾向有り。
指数関数的にインフラコスト増加	新たなマイクロサービスごとに、テスト スイート、デプロイ ガイド、インフラ考慮、監視ツール、その他独自のコストがかかる可能性がある。
コードの所有権欠如	導入されるサービス数が増えるにつれ、サービスを実行するヒト・チームの数が増加する可能性あり。開発ドキュメントの整備を怠ると情報統制は取れなくなる。

サーバーレスを導入するに当たり、上記のモノリシックアーキテクチャーとの違いを適切に理解する必要があります。

では、いよいよサーバーレスについて触れていきます。

サーバーレスが組織の技術や開発文化を次世代へ導く理由

早速、サーバーレスが組織の技術や開発文化を次世代へ導くと考えられる、7つの理由を見ていきましょう。

1. 疎結合なコンポーネントの組み合わせで機能を構築可能

大規模化してもソースコードが属人化しない

サーバーレスを使用したシステム構成では、AWS Lambda、AWS AppSync等のサーバーレス製品を組み合わせることで様々な機能を構築可能です。例えば認証機能を構築する場合、PHP でいえば Laravel、Java でいえば PlayFramework の認証モジュールを使用することになるかと思いますが、サーバーレスでは AWS Cognito やweb3Auth 等を使用し、ビジネスロジックの実装無しで機能を実現可能です。

また、サーバーレスは一般的には FaaS（Function as a Service）アーキテクチャーを採用しますが、AWS Lambda 等で関数型プログラミングを活用すれば、入出力として何が期待されているかが常に分かり、洗練されたソースコードの実装が可能となりとなります。加えて AWS Lambda は冪等性を持つコードとなるためサーバーレスによるビジネスロジックの実装は変更しやすく、ステートレスなコードを促すことになります。

簡単にいえば、大規模化してもソースコードが属人化せず、誰でも参加しやすいプロジェクトメイキングを可能にします。

デプロイが簡単

個々のマイクロサービスは基本的には疎結合に構築されるため、デプロイ時に他のコンポーネントに影響を出しません。つまり、デグレードの確率を格段に下げることが可能です。

サーバーレスの場合、コンポーネントを必然的に小さくせざるを得ません。例えば、AWS Lambda では長時間の処理は実行できません（少なくとも現時点では）。2022年7月の時点では、設定されたタイムアウトの最大値により、15分以上を要する処理は実行できません。（規定のタイムアウト時間以上を必要とする処理を実行する場合は、AWS ECS のようなサービスでサーバーレスコンテナに切り替えることもできます）

何にせよ、大きな機能を小さなコンポーネントに分割する必要があるということは、ベストプラクティスとして抑えておきましょう。

また、サーバーレスと言っても AWS Lambda や AWS ECS のような実行環境に限定されるわけではありません。他にも様々な機能を持つサーバーレスコンポーネントが存在し、それらをうまく組み合わせることでひとつの機能をきわめて効率よく実行する事が可能です（今回は AWS の例を挙げていますが、他のクラウドベンダーでも同じことが言えます）。

• AWS SQS – メッセージキューイングサービス
• AWS SNS – プッシュ型通知サービス
• AWS SES – メール送信サービス
• AWS S3 – 大規模なデータを保存可能な高可用性ストレージサービス

2. 自己完結型の実行環境の実現

サーバーレスでは、コンポーネント単位で実行環境を作り上げる必要があります。例えば AWS Lambda（NodeJS）でいえば、ビジネスロジックの実行に必要な各種モジュールをバンドルしたソースコードをデプロイする必要があります。

実行環境で主に注視すべきポイントは以下です。

• パッケージの依存関係を解決した上でソースコードをデプロイ
• 必要な環境変数を設定
• バイナリ操作などの OS に依存するビジネスロジックは Docker の採用を検討

FaaS かサーバーレスコンテナ（Docker）のどちらを使用するかにかかわらず、常に冪等性・再現性のあるコードが求められます。

3. より頻繁なデプロイ

コンポーネントが小さく、自己完結的で互いに独立して実行できる場合、より頻繁なデプロイが可能となります。個々のデプロイは必然的に独立性が高まります。

4. 最小権限のセキュリティ原則

理論的には、サーバーレスコンポーネントに対しすべての実行権限を持つ admin ユーザを利用することもできます。しかし、AWS Lambda のようなサーバーレス製品には、実行に必要な最小限のアクセス権限を付与します。

加えて IAM ロールを使用することで、資格情報のハードコーディングを避け、外部サービスや環境変数に秘密の保存を頼らずに済みます。

このように、小さなサーバーレスコンポーネントでは、サービス単位、あるいは機能単位での権限付与がよしとされ、そのような設計を行うように促されます。

5. 高可用性とフォールトトレランスを容易に実現

ほとんどのサーバーレスコンポーネントは、高可用性 (HA) があるように設計されています。例えば、AWS Lambda はデフォルトで複数のアベイラビリティゾーン (AZ) に展開され、非同期呼び出しに失敗した場合は2回リトライします。勿論非サーバーレスリソース（モノリシックアーキテクチャー）でも同じことができますが、簡単ではありません。

同様に、コンテナ化された ECS のタスク・DynamoDB のテーブル・S3 のオブジェクトも、耐障害性のために複数のアベイラビリティゾーン (またはサブネット) にデプロイされます。

6. 常に再現性のある実行が可能

読者の方は、これまででこのような経験はありませんか？

• インスタンスにモジュールをインストール、サーバーが完璧に構成されるように、入念に確認/構築
• しかし、ある日オフィスに出社すると、サーバーがダウンしていることに気づく
• バックアップもなく、システム全体を構成するために使用したコードも保存していない
• さらに、様々なリソースへのユーザーアクセスを定義するための環境変数があることが判明
• ただ、それがすべて消えてしまったため、初めからやり直さなければならない…

このように、ひとつのサーバーに頼りきりの状態で、それがダウンした際に失うものは非常に大きくなります。

しかしサーバーレスの場合、失うものはありません。サーバーレスのアプローチでは、コンピューティングリソース（AWS Lambda, Fargate 等）は常にステートレスで、かつホットスタンバイしていません。そのため、どのサーバーでも実行できる自己完結型のコードを構築することになります。

このアプローチのおかげで、サーバーがダウンしてもサーバーレスアプリケーションは再実行が常に容易なため、実行に必要なすべての新しいリソースが実行の都度新しく用意されます。

一度この再現可能なプロセスを構築すれば、ここまで紹介してきたように多くのメリットを享受できます。

7. 実績のある既存コンポーネントを利用できる

サーバーレス・アーキテクチャを構築する場合、メッセージキューイングシステムや通知サービスを独自に構築することはめったにありません。一般的にはクラウドプロバイダーが提供する十分にテストされた安定稼働しているサービスを使うことになります。AWS をベースにした例がこちらです。

• メッセージキューが必要な場合 → SQS
• 通知を送る必要がある場合 → SNS
• 機密を扱う必要がある場合 → Secrets Manager
• REST API を構築する必要がある場合 → API Gateway
• 権限やユーザーアクセスを管理する必要がある場合 → IAM or Cognito
• Key-Value ペアでのデータ可能 → DynamoDB

経験豊富なエンジニアに、上記のようなビルディングブロック (SQS・SNS・IAM・S3 など) と、クラウドプロバイダが完全に管理するプラットフォームを提供すれば、アーキテクチャ全体の保守性を大幅に向上させることができますね。

そして、これらのようなサービスを利用することで、様々なユースケースを高速・柔軟に構築することが可能となります。

サーバーレスで実現しにくいこと…

さて、ここまではサーバーレスの有用さについて紹介してきましたが、サーバーレスで実現しにくいことがあるのも事実です。

たくさんの小さな部品で構成されているものは、全体像が見えにくくなりやすいです。また、ワークフローの一部に障害が発生した場合、システムの個々の要素間の関係を確認して対処するのが難しいことがあります。

開発者は常に監視ツール、シーケンス図を作成するなどして、ワークフローを可視化・管理することが求められます。

まとめ

今回は、組織の技術や開発文化を次世代へと導くサーバーレスの有用さを紹介しました。

本記事のように、互いに独立してデプロイできる小さな自己完結型コンポーネントの促進や、インフラ全体のセキュリティ向上と高可用性の実現など、サーバーレスの導入にはたくさんのメリットがあります。

導入を悩んでいる方は、ぜひサーバーレスでの開発を検討してみてはいかがでしょうか。

サーバーレスに関する開発相談は、お気軽にお問い合わせください。