サーバレス化でシステム基盤のライフサイクルは変わるか

はじめに

オープンシステムの寿命は5～7年がひとつの目安となります。システム基盤の刷新タイミングはハードウェアの減価償却完了であったり、リース期限であったり、保守サポート期限（End Of Life、EOL）であったりなど、ハードウェアに依存してきました。
2000年代に入ってサーバ仮想化によりハードウェアのみ差替えることができると、ライフサイクルは仮想化ソフトウェアやOSなどより上位レイヤのEOL依存にシフトすることになりました。さらに近年はコンテナやマネージドサービスによるサーバレス化に注目が集まっていますが、これによりシステム基盤のライフサイクルがどのように変わってくるのか、また、その変化に対して準備すべきことをアマゾン ウェブ サービス（AWS）での構築・運用保守の経験から紹介していきます。

OSのEOLを気にする運用

AWSでのシステム構築が進んでいった当初はAmazon EC2がメインで利用されていたため、ハードウェアのライフサイクルからの脱却こそできましたが、OSのライフサイクルは依然と残っており、構築時に選定したOSバージョンがシステムロンチ後、あと何年使うことができるかを気にかけることになります。筆者はロンチして3年後には次期バージョンのOS更改の検討を開始する、といった、落ち着く暇がないシステムを実際に経験しています。
また、システムに導入するOSは1～2種類に絞られるため、OSのEOLを迎えると全面更改となってしまいます。数年ごとに迎える一大イベントはハードウェア依存であった時代とあまり変わらないのではないでしょうか。

以下は筆者が担当している2019年にロンチしたWebシステムのEOLロードマップとなります。通常ですとAmazon LinuxのEOLとなる2023年6月までに全面更改が必要となってきます。

サーバレスアーキテクチャにおけるEOL対応

サーバレス化のアプローチとしてAmazon ECSやAmazon EKSを利用したコンテナがあります。AWS Fargateが登場した際は「コンテナ基盤の管理をAWSへオフロードさせることができ、OSのEOLを気にすることが無くなる。更には、コンテナ上で起動しているプロセスに必要なミドルウェアのEOL管理のみに集中でき、EOLを迎えたミドルウェアが起動しているコンテナを個別で差替えることができる。」という理想的な運用ができるのではないかと夢物語を描いていたのですが、結果的に間違いでした。

コンテナのDockerイメージにはプロセスを起動させるためのライブラリ等が含まれており、それはベースDockerイメージの元となるOSから提供されているため、ライブラリのEOLはOSと同じであり、結局OSのEOLの呪縛から逃れることはできないことが分かりました。結果的にOSのEOLを迎えるタイミングでそれがベースとしているコンテナのDockerイメージの更改が発生してしまうことになります。

筆者が担当しているお客様のシステムでは、ベースDockerイメージの選定にあたってはリソース効率を意識した軽量イメージやよりEOLの長いRHELベースのコンテナを利用する案を検討しましたが、お客様システムでの商用稼働を考えるとAWSとの親和性やサポート充実性の優位点からAmazon Linux系が適切という結論に至り採用しました。したがって、現稼働バージョンであるAmazon Linux 2のEOLを迎える2025年にはコンテナの全体的な刷新が発生することになります。ここで威力を発揮するのがCodeシリーズ（CodeCommit、CodeBuild、CodeDeploy、CodePipeline）によるCI/CDで、コンテナ化とあわせてリリースフローをCI/CD化しておくと、Dockerイメージの更改を通常のCI/CDパイプラインに乗せることができるため、従来のような大規模更改にはならないでしょう。

サーバレス化のもう1つのアプローチは、Amazon RDS・AWS Lambda・Amazon ElastiCacheのようなAWSのマネージドサービスを利用することです。こちらもOS層以下の管理をAWSへオフロードすることでOSのEOLを気にすることが無くなります。コンテナ同様サービス上で稼働しているエンジン（Amazon RDSであればMySQL・PostgreSQLなど、AWS LambdaであればNode.js・Python・Rubyなど、Amazon ElastiCacheであればMemcache・Redisなど）にはEOLがありますので、それぞれのEOLを迎えるタイミングでバージョンアップによる更改が必要となってきます。OSのインストール・設定が不要で、新バージョンのインスタンス・エンジンを立ち上げるだけなので手軽に見えますが、コンテナに比べてバージョンアップ時の影響範囲は大きくなりますので、しっかりとした動作確認と移行計画が必要となります。

また、注意すべき点としては、マネージドサービスで利用されているエンジンはミドルウェア提供元本家のEOLとは違うAWS独自のEOLが設定されていることがある点です。例えば、Amazon RDS for PostgreSQLのEOLは本家を参考にできますが、Amazon Aurora PostgreSQLは新バージョンのリリースタイミングが本家やAmazon RDS版よりも遅くEOLが読めないため、バージョンアップの候補から外すことを選択するお客様もおりました。

サーバレスアーキテクチャのEOL対応を日々の運用保守でバーツ交換のように実現するには、差替える対象（ベースDockerイメージやミドルウェア・エンジン）毎にどの範囲の動作確認（アプリケーション含め）を実施するかをシステム構築時に決めて、システムテストや運用テストなどで検証しておく必要があります。ここが曖昧となると、差替える度に全機能を動作確認することになり、かえってTCOの増加を招いてしまいます。また、当然ですがパーツ毎の差替えが確実にできるように機能やプロセスは疎結合となるように設計し事前検証しておきましょう。

最後に

本記事ではサーバレスアーキテクチャにおけるシステム基盤ライフサイクルの実態を解説しました。大規模で集中的に行う今までのシステム更改を、ある程度小規模分散化する道筋はできたのではないでしょうか。これにより数年毎に訪れるシステム更改のための経営資源の負担軽減に寄与し、お客様は新たなビジネスの創出にその資源を集中させることが期待できます。

TISではAWSのサーバレスアーキテクチャを利用したWebシステム構築、既存のオンプレミスサーバやAmazon EC2からサーバレスアーキテクチャへのマイグレーションをご支援することができます。さらにサーバレスアーキテクチャシステムの運用保守まで対応できるエンジニアとノウハウが集まっていますので、ご検討の際はTISまでご相談頂けますと幸いです。

著：TIS株式会社
IT基盤技術事業本部 IT基盤技術事業部
IT基盤エンジニアリング第2部 主査
束野　敬一郎