re:Invent の発表から読む AWS の 3 年後 - サービスのライフサイクルと廃止の法則
CodeCommit の新規受付停止、SimpleDB の事実上の終了など、AWS サービスにも寿命があるという事実を直視し、サービスのライフサイクル分析と「消えないサービス」を見極める技術選定の視点を提供します。
AWS サービスにも寿命がある
AWS は「一度リリースしたサービスは廃止しない」という暗黙の信頼の上に成り立ってきました。しかし、2024 年 7 月に状況が変わりました。AWS は CodeCommit、Cloud9、S3 Select、CloudSearch、SimpleDB など複数のサービスについて、新規顧客の受付を停止すると発表しました。既存顧客は引き続き利用できるものの、新機能の追加は行わないという方針です。OpsWorks Stacks は 2024 年 5 月にサービスを完全に終了しました。これらの動きは、AWS のサービスにもライフサイクルがあり、永続的な存在ではないことを明確に示しています。技術選定において「AWS のサービスだから安心」という前提は、もはや無条件には成立しません。
消えたサービスたちの共通点
廃止または縮小されたサービスには共通するパターンがあります。SimpleDB は 2007 年にリリースされた AWS 初期の NoSQL データベースですが、2012 年に DynamoDB がリリースされると急速に存在感を失いました。AWS のサービス一覧からも姿を消し、コンソールからのアクセスもできなくなりましたが、API は長年にわたって維持されていました。2024 年にようやく新規受付が停止されています。CodeCommit は AWS のマネージド Git リポジトリサービスでしたが、GitHub や GitLab といった専業サービスとの競争に勝てませんでした。Cloud9 はブラウザベースの IDE でしたが、VS Code のリモート開発機能や GitHub Codespaces の台頭により、差別化が困難になりました。OpsWorks は Chef や Puppet を使った構成管理サービスでしたが、コンテナとサーバーレスの普及により、従来型の構成管理ツールの需要自体が縮小しました。これらに共通するのは、より優れた代替手段が登場したこと、AWS のコアインフラではなく周辺ツールであったこと、そして利用者数が一定の閾値を下回ったことです。
サービスのライフサイクル 4 段階
AWS サービスのライフサイクルは 4 つの段階に分けられます。第一段階は Preview です。re:Invent などのイベントで発表され、限定的なプレビューとして提供されます。この段階では SLA がなく、API が変更される可能性があり、本番ワークロードには適しません。注意すべきは、Preview のまま GA に至らないサービスも存在することです。第二段階は GA (一般提供) です。SLA が設定され、本番利用が可能になります。ただし、GA 直後のサービスはドキュメントが不十分だったり、エッジケースでの挙動が安定しなかったりすることがあります。GA から 1 年程度は慎重に評価する期間と考えるのが安全です。第三段階は成熟期です。機能が安定し、ベストプラクティスが確立され、エコシステム (サードパーティツール、コミュニティ、書籍) が形成されます。S3、EC2、Lambda、DynamoDB はこの段階にあり、AWS の収益の柱として大規模な投資が継続されています。第四段階は縮小・統合です。新機能の追加が止まり、ドキュメントの更新頻度が下がり、re:Invent での言及がなくなります。最終的に新規受付の停止や、後継サービスへの移行推奨が行われます。
消えないサービスの条件
長期的に存続するサービスには共通する特徴があります。第一に、他のサービスの基盤になっていることです。S3 は AWS の多数のサービスがデータストアとして利用しており、S3 を廃止することは事実上不可能です。EC2 は ECS、EKS、RDS、Redshift など多くのサービスの実行基盤です。IAM はすべてのサービスの認証・認可の基盤です。これらの基盤サービスは、依存関係の深さゆえに廃止のコストが極めて高くなります。第二に、AWS の収益の柱であることです。EC2 と S3 は AWS の売上の大きな割合を占めており、これらのサービスへの投資は継続されます。第三に、業界標準やオープンソースのエコシステムと結びついていることです。EKS は Kubernetes、RDS は PostgreSQL や MySQL、Lambda は FaaS (Function as a Service) という概念自体と結びついています。業界標準に基づくサービスは、AWS 固有の実装が廃止されても、標準自体が存続する限り後継が提供されます。逆に、AWS 独自の技術に基づくサービスで、業界標準との接点が薄いものは、代替手段の登場により廃止されるリスクが高くなります。
技術選定の実践的フレームワーク
新しい AWS サービスの採用を判断する際、以下のフレームワークが有効です。まず、そのサービスが GA からどれくらい経過しているかを確認します。GA から 2 年以上経過し、継続的に機能追加が行われているサービスは、成熟期に入っている可能性が高く、安定した選択肢です。次に、そのサービスが AWS の他のサービスの基盤になっているかを確認します。AWS のドキュメントやアーキテクチャガイドで頻繁に参照されるサービスは、エコシステムの中核に位置しており、廃止リスクが低いと判断できます。そして、最も重要な問いを自分に投げかけます。このサービスが 3 年後に存在しなかったらどうするか。Exit Strategy を事前に設計しておくことが、技術選定における最大のリスク軽減策です。具体的には、サービス固有の API に直接依存するのではなく、抽象化レイヤーを設けてサービスの切り替えを容易にする設計を採用します。データのエクスポート手段を確保し、定期的にエクスポートが正常に動作することを検証します。代替サービスの候補を事前に調査し、移行パスを概算しておきます。 技術選定やアーキテクチャ判断の知見を深めるには関連書籍 (Amazon) も参考になります。
まとめ
AWS サービスにもライフサイクルがあり、永続的な存在ではありません。2024 年の CodeCommit、Cloud9、SimpleDB などの新規受付停止は、この事実を明確に示しました。消えないサービスの条件は、他のサービスの基盤であること、収益の柱であること、業界標準と結びついていることです。技術選定では「このサービスが 3 年後に存在しなかったらどうするか」という問いを常に持ち、Exit Strategy を事前に設計しておくことが、長期的に安定したシステムを構築する鍵です。