IT 運用から開放された人々の "サーバーレス" ライフに迫る

突然ですが、ずっと前にドラムをやっていましたが、最近できておらず、電子ドラムを買いたいと前から思っています。しかし家にスペースが無いのが問題です。ですが、とりあえず買ってしまって、本当に場所が足りなくなってきたら売れば良いかなとも思い、そろそろ近いうちに買ってしまおうかと虎視眈眈と狙っています。

理想を言えば、使いたい時にだけ電子ドラムが家に現れて、シンバルやタムの数も自由に増減できて、使わない時は家からなくなって、さらに演奏のタム回し中にドラムのスティックが折れたりしたら直してくれて、常に最新モデルが使え、演奏に注力できたら良いのに・・・

電子ドラムでそんな都合の良いことはできませんが、モダンなアプリケーション開発の場合なら、似たようなことを AWS で実現できます。

そう、“サーバーレス” なら。

サーバーレスを活用すれば、必要な時だけリソースを確保して利用でき、使わない時はリソースを解放することができます。また、常に最新の環境が利用可能になり、メンテナンスの手間も軽減されます。

それでは、サーバーレスについてさらに知っていきましょう。

サーバーレスにおいては、従来のシステム構成と比較すると、スケーリングや可用性など、考慮すべき点が少なくなります。
また、それらは日々進化しています。例えば次のアップデートでは、AWS Lambda 関数がより速くスケールするようになる 等、サーバーレスの利便性は日に日に高まっています。

開発者がインフラ担当者と調整して環境を入手するリードタイムが不要になるという点もメリットです。

サーバーレスの普及が進む中でも、Amazon EC2 + Amazon RDS という組み合わせの構成はなお多く採用されています。しかし、現在 Amazon EC2 と Amazon RDS を利用しているケースの中にも、AWS Lambda や Amazon DynamoDB といったサーバーレスを活用した構成の方が適切な場合も多くあると考えられます。

この記事では、コンピューティングサービスとして Amazon EC2 と AWS Lambda、データベースサービスとして Amazon RDS と Amazon DynamoDB を比較の一例として、運用時のバージョンアップなどの対応の有無に焦点を当てて比較します。

サーバーレスでは運用がどれぐらいラクになるのかを、具体的に見ていきましょう。

AWS Lambda はお客様に代わってコンピューティングインフラストラクチャを運用し、健全性チェックの実行、セキュリティパッチの適用、その他の定期的なメンテナンスを担当します。

まず比較表をご覧ください。この表から、AWS Lambda の方が対応が必要な項目が少ないことがおわかりいただけるかと思います。その後で、より詳細な内容について説明させていただきます。

• Amazon EC2 : セキュリティの強化・バグ修正とパフォーマンス改善・新機能の追加の恩恵を受けたり、継続してサポートを受けるための OS のバージョンアップは、お客様により実施していただく必要があります。
  ※参考ドキュメント : Amazon Linux 2 に関するよくある質問 » / AWS と Microsoft に関するよくある質問 » 
  
• AWS Lambda : お客様による対応は不要です。

• Amazon EC2 : 急速に進化するテクノロジーに関して言えば、通常、最新の世代は料金に見合った最高のコストパフォーマンスを提供するため、お客様においてはテクノロジーの進化を活用することが推奨されます。そのためのインスタンスタイプの変更は、お客様により実施していただく必要があります。
  ※参考ドキュメント : Amazon EC2 のよくある質問 »
  
• AWS Lambda : お客様による対応は不要です。

• Amazon EC2 : EC2 インスタンスのオペレーティングシステムやアプリケーションに対するパッチ適用やそれらの更新およびセキュリティ確保を定期的に行うよう推奨しており、お客様により実施をしていただく必要があります。
  ※参考ドキュメント : Amazon EC2 での更新管理
  
• AWS Lambda : お客様による対応は不要です。

• Amazon EC2 : ドライバーを最新の状態に維持し、最新の問題修正とパフォーマンス強化がフリート全体に適用されるようにすることが推奨され、お客様により実施をしていただく必要があります。
  参考ドキュメント »
  
• AWS Lambda : お客様による対応は不要です。

• Amazon EC2 : AWS は定期的に定常メンテナンスを実行し、インスタンスへの影響を最小限に抑えています。ただし、場合によっては、スケジュールされたイベントをお客様に送信することがあります。スケジュールされたイベントとは、AWS が開始する計画されたメンテナンスのための停止、再起動のことです。インスタンスをお客様により停止または終了して、より早く開始することもできます。
  ※参考ドキュメント : Amazon EC2 のメンテナンスのヘルプページ »
  
• AWS Lambda : お客様による対応は不要です。

ランタイムに関して、組織やチームによって役割分担が異なる可能性があり、馴染のない方もいらっしゃるかもしれません。
ランタイムとは、プログラミング言語で書かれたプログラムを実行するために必要な環境を指します。具体的には、インタープリタや、ランタイムライブラリによるメモリ管理、ファイル入出力、ネットワーク通信の管理、例外処理などの機能を提供します。
例えば、Java の Java Runtime Environment(JRE) には、Java バイトコードを実行する Java 仮想マシン (JVM) と Java 標準ライブラリが含まれています。もう一つの例として、Python のランタイムには、インタープリタと標準ライブラリが含まれています。

• Amazon EC2 : セキュリティの強化・バグ修正とパフォーマンス改善・新機能の追加の恩恵を受け、他のライブラリやフレームワークとの互換性を保つために、お客様にてより新しいランタイムに更新していくことが推奨されます。
  
• AWS Lambda : Lambda は、実行環境で関数を呼び出します。実行環境では、関数の実行に必要なリソースを管理するセキュアで分離された、言語固有のランタイム環境が提供されます。
  Lambda の 責任共有モデル では、Lambda はセキュリティパッチやその他の更新プログラムを使用して、ランタイムを定期的に更新する責任を担います。
  サポートされているランタイムの使用における関数のアップグレード (依存関係を含め、関数コードへの更新の適用) は、責任共有モデルに基づくお客様の責任となります。Lambda によって非推奨になるランタイムで実行されている関数がある場合、サポートされているランタイムへの関数の移行を強くお勧めしており、お客様により実施していただく必要があります。
  ランタイムが非推奨になると、関数を引き続き実行することはできますが、継続したランタイムへのセキュリティ更新、テクニカルサポート、修正プログラムの提供の対象ではなくなり、既存の Lambda 関数の更新をすることができなくなっていきます。
  Lambda 関数をサポート対象のランタイムにアップグレードすることは手間がかかる作業ですが、非推奨のランタイムのままでいると、アプリケーションに潜在的な脆弱性が残り、将来的にリスクにさらされる可能性があります。アプリケーションの健全性と持続可能性を確実にするための賢明な投資となるはずです。

今回は Amazon CloudWatch の利用を例として比較をします。

• Amazon EC2 : Amazon EC2 ではデフォルトで 、インスタンスのステータスチェックの結果や、CPU 、ディスク、ネットワーク等に関するメトリクスを Amazon CloudWatch でモニタリングできます。さらに、CloudWatch エージェントをインストールすることで、メモリ使用率等の内部システムレベルのメトリクスの収集や、Amazon CloudWatch Logs へのログ出力が可能になります。エージェントのインストールはお客様により実施をしていただく必要があります。また、エージェントの更新についてもお客様により考慮が必要です。
  ※参考ドキュメント : Amazon EC2 のモニタリング » / インスタンスの利用可能な CloudWatch メトリクスのリスト表示 »
  
• AWS Lambda : Lambda は、ユーザーに代わって Lambda 関数を自動的に監視し、Amazon CloudWatch を通じてメトリクスを報告します。そのため、お客様によるエージェントの管理は不要です。また、Lambda Insights を有効にすることで、より詳細な情報を取得できます。なお、AWS Lambda ではサーバーを管理する必要がないため、インスタンスのステータスチェックのようなメトリクスを気にする必要はありません。ログについては、言語の標準出力機能の利用により Amazon CloudWatch Logs へのログ出力が可能です。
  ※参考ドキュメント : Lambda 関数のモニタリングおよびトラブルシューティング » / Lambda 関数のメトリクスの使用 »

• Amazon EC2 : Elastic Load Balancing と Amazon EC2 Auto Scaling をアプリケーションアーキテクチャに追加することで、アプリケーションに対する需要の増減に応じて、インスタンスを起動または終了でき、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲットに自動的に分散させることができます。そのための設定や運用中の設定の調整はお客様により実施していただく必要があります。また、Auto Scaling グループで利用する Amazon マシンイメージ (AMI) を管理していく必要があります。
  ※参考ドキュメント : 既存のインスタンスからのパラメータを使用して Auto Scaling グループを作成する »
  
• AWS Lambda : AWS Lambda 関数が受け取るリクエストが増えると、Lambda が実行環境数のスケーリングを自動的に処理し、これはアカウントの同時実行上限に達するまで行われるため、スケーリングのためのお客様による対応は不要です。
  ※参考ドキュメント : Lambda 関数のスケーリング »
   

Amazon DynamoDB には、プロビジョニングやパッチ、管理用のサーバーだけでなく、インストール、メンテナンス、または運用するソフトウェアもありません。Amazon DynamoDB にはバージョン (メジャー、マイナー、パッチ) がなく、メンテナンスウィンドウもありません。また、Amazon DynamoDB はダウンタイムなしのメンテナンスを提供します。

Amazon DynamoDB は NoSQL データベースサービスであり、リレーショナルデータベースとは異なる性質を持っているため、すべてのシステムに適用できるわけではありません。システムの要件や特性を十分検討し、適切なアプローチを選択することが重要です。

コンピューティングサービスの比較と同様に、データベースサービスについても、まず比較表をご覧ください。その後で、より詳細な内容について説明させていただきます。

• Amazon RDS : AWS では、定期的にメジャーまたはマイナーのエンジンバージョンの廃止を行います。アップグレードに伴う対応はお客様により実施をしていただく必要があります。お客様によるアップグレードがされない場合、廃止の発表から一定期間が経過すると、スケジュールされたメンテナンスウィンドウ中にアップグレードされます。データベースエンジンをアップグレードするには、ダウンタイムが必要です。
  ※参考ドキュメント : Amazon RDS よくある質問 »
  
• Amazon DynamoDB : お客様による対応は不要です。この点は、Amazon DynamoDB の特に大きなメリットであると考えられます。
  システム運用では、機能変更の必要がなくとも、DB などの製品のバージョンアップサイクルに合わせて不定期に作業が発生するのが一般的です。しかし、バージョンアップ自体が目的となると、コストと労力の無駄が生じ、価値を感じにくい作業にリソースを割かれることで、システムはコストセンターになってしまう恐れがあります。
  "バージョンレス" である Amazon DynamoDB では、AWS によりソフトウェアが継続的にアップグレードされるため、大がかりなバージョンアップ作業が不要になります。これにより、コストと労力を最小限に抑えながら、常に最新の機能を活用できます。
   

• Amazon RDS : Amazon RDS 認証局証明書には有効期限があり、RDS DB インスタンスへの接続に証明書検証付きの Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用しているか、使用する予定がある場合は、期限切れに伴う 証明書のローテーション をお客様により実施をしていただく必要があります。SSL/TLS とサーバー証明書を接続に使用するクライアントアプリケーションの更新も必要になります。
  
• Amazon DynamoDB : お客様による対応は不要です。
   

• Amazon RDS : Amazon RDS では、Amazon RDS リソースのメンテナンス を定期的に実行します。一部のメンテナンス項目では、Amazon RDS が DB インスタンスを少しの間オフラインにする必要があり、アプリケーションへの影響を考慮する必要があります。
  
• Amazon DynamoDB : お客様による対応は不要です。
   

• Amazon RDS : 最高のパフォーマンスを得るために最新世代のインスタンスのご利用をお勧めしています。DB インスタンスクラス の変更が必要な場合、お客様により実施をしていただく必要があります。
  
• Amazon DynamoDB : お客様による対応は不要です。
   

• Amazon RDS : Amazon RDS では 様々なモニタリングツール が提供されており、それらを利用することができます。お客様による監視用エージェントの管理は不要です。Amazon CloudWatch と統合されており、CPU 使用率やメモリー、ディスクに関する様々なメトリクスを確認することができます。また、Performance Insights を有効にすることで、既存の Amazon RDS モニタリング機能を拡張して、データベースのパフォーマンスを明確にし、分析しやすくすることができます。
  
• Amazon DynamoDB : Amazon DyamoDB では 様々なモニタリングツール が提供されており、それらを利用することができます。お客様による監視用エージェントの管理は不要です。Amazon CloudWatch と統合されており、指定された期間に消費された読み込みまたは書き込み容量ユニットの数などのメトリクスを確認することができます。DynamoDB が自動的に必要なだけのリソースを提供するため、リクエストを処理するのに必要な CPU 使用率やメモリ使用率などをお客様が管理する必要がありません。
   

• Amazon RDS : Amazon RDS はマネージドデータベースサービスであり、AWS がほとんどの管理タスクを担っているため、お客様によるデータの耐障害性とバックアップのためのサーバー管理は不要です。ただし、データの 耐障害性 とバックアップを確保するための適切な設定が必要不可欠です。
  Amazon RDS が提供する、バックアップと復元や、レプリケーション、フェイルオーバーなどの機能を活用し、ワークロードに合わせて設定を行うことが重要です。
  例えば、マルチ AZ 配置 を選択すると、AWS が 1 つまたは複数のセカンダリスタンバイ DB インスタンスを別のアベイラビリティーゾーンで自動的にプロビジョニングして管理します。プライマリ DB インスタンスは、アベイラビリティーゾーン間で各セカンダリ DB インスタンスにレプリケートされます。障害を検出すると、Amazon RDS は手動の介入なしにスタンバイインスタンスに自動的にフェイルオーバーします。
  
• Amazon DynamoDB : Amazon DynamoDB は、サーバーレス NoSQL フルマネージドデータベースであるため、お客様によるデータの耐障害性とバックアップのためのサーバー管理は不要です。可用性、耐久性、フォールトトレランスは組み込まれており、オフにすることはできないため、これらの機能に合わせてアプリケーションを構築する必要がありません。
  Amazon DynamoDB は、任意の量の読み取りトラフィックに対応するように自動的にスケールアウトされるため、リードレプリカは必要ありません。また、同じ AWS リージョン内の 3 つの AZ 間でデータが同期的にレプリケートされるため、AZ に関する考慮も不要です。
  オンデマンドバックアップと復元や、ポイントインタイムリカバリ機能を提供しており、それらを利用することができます。
  ※参考ドキュメント : Amazon DynamoDB での耐障害性と災害対策 »
   

Amazon EC2 + Amazon RDS といった、従来から多く採用されてきた構成に比べ、サーバーレスを用いた構成は運用時のメンテナンス管理工数が大幅に削減できることを解説しました。
サーバーレスでは、IT運用に携わる皆様が心理的にも負担を感じていた、サーバーの起動・停止や切り替え、死活監視、OSやミドルウェアの更新、セキュリティパッチの適用など、さまざまな運用タスクから解放されます。これによりビジネスロジックの開発に注力できるのがサーバーレスの大きな魅力です。

最後に、「サーバーレスに関する情報はあちこちにあるけれどどこから始めたら良いかわからない」、そんな開発者のための「今から始めるサーバーレス」情報をご紹介させていただきます。その中でも「サーバーレスの始め⽅」は、これからの人向けの典型的ステップとして、参考にすると良い技術資料や次のステップとなるハンズオンを、おすすめの順番で紹介していますので是非ご覧ください。

この記事を機に、より多くの方がサーバーレスの利用を検討してくださることを願っております。