それサーバレスでできません？ 〜①サーバレスアプリケーションとは・採用する目的

投稿の目的

自粛期間から始めた、PaaS、CI/CD、アジャイルについての学習のアウトプットの一環として実施。
(備忘録としての意味合いが強いので、内容に誤りがある場合は、温かい目線で指摘いただけると幸いです)

サーバレスアーキテクチャ(以下サーバレス)とは

Webサービスを例にした場合、従来サービスを開始するには、サーバー(外側の箱)とアプリケーション(中身)を用意する必要がありました。
①サーバーの用意(物理/仮想環境、オンプレ/クラウドを問わず)
②サーバーに必要なミドルウェア、ソフトウェアをインストールする。
③アプリケーションコードを書く
④③で作成したコードをビルドする

サーバレスを採用することで、上記手順の内①~②を実施する必要がなくなります。正確には、プラットフォーム側(クラウドを使用する場合はクラウドベンダー)が担当してくれるといった形になります。
サービス開始時の手間が減るのは勿論ですが、サービス開始後は、OSのバージョンアップ、セキュリティバッチの更新、利用料に応じたスケールアップといった管理についてもプラットフォーム側が担当してくれるため、運用面での負荷軽減も期待できます(長所については、次トピックで解説します)。

サーバレスの長所・短所

長所
①リソースに対する金銭コストが抑えられる
サーバーを起動している時間ではなく、処理が行われた時間に対してのみの課金であるため、金銭面でのコストが格段に低くなる。

②運用コストが低くなる
スケーリングやパッチ適用などの運用でのタスクを行う必要がないサービスが多いため、運用面での手間が少なくなる。結果アプリケーションの開発やサービス改善にリソースを割り当てる余裕が出る可能性が高い。

短所
①プラットフォーム間での互換性が少ない(≒移行コスト高)
AWS、GCP、Azure間で使用するリソースの構成が変わるため、マルチクラウドでの冗長構成やサービスの移行が行えない可能性が高い。
また、オンプレで運用していたサービスを移行する際は、リプラットフォームが必要となる。

②機能に制限がある(アンチパターンの存在)
実行時間やデプロイサイズに制限が存在する。例として、データ移行のような長時間の処理についてはクラスターやインスタンスが必要となる。
LambdaからRDSが使用できるようになるなど、毎年アップグレードによりアンチパターンは減っているが、まだ制限が存在する。

③開発・運用側にスキルセットがない場合がある
サーバレスでのアーキテクチャを設定できる技術者が少ないため、人材の確保・キャッチアップにコストがかかる。

検証の進め方(=次回投稿からの進め方)

テーマ：
レガシーな構成となっているWebアプリケーションをサーバレスで構築する。

基本ルール：
・環境はAWSのサービスを使用して構築
・可能な限り、AWSのマネージドサービスを使用した構成となるよう改修を行う。
・リポジトリによるバージョン管理、CI/CDパイプラインを使用する(運用の効率化が目的であるため)。

改修前の構成（レガシーな構成）
・Webサイト(SPA)：フレームワークはVue.jsを使用。ビルドはEC2内で実行。
・データベース：MySQLのRDSを利用。
・API：言語はNode.js, Python, PHP,のどれか。EC2内で管理。
※後続の回で各言語のパターンを取り扱う
・認証：ユーザー情報はRDSで管理。認証はEC2内のAPIを利用。
・コンテンツ：S3で管理