はじめに
NTTデータの奥村です。最近、「AWSを使ったシステム開発はコモディティ化しているのではないか」という意見を耳にする機会が増えてきました。しかし、本当にそうでしょうか？
本記事では、いくつかの観点でAWSシステム開発が本当にコモディティ化しているのかを考えてみたいと思います。
コモディティ化とは？
まずは言葉の定義から確認します。コモディティ化とは、製品やサービスが差別化できなくなり、価格競争に陥る現象を指します。AWSを使ったシステム開発が誰でも同じように構築でき、差別化が難しくなっている状態を指していると考えられます。
AWSを用いたシステム開発は本当にコモディティ化しているのか？
一見すると、AWSに関するドキュメントはQiitaを始めとして様々なブログプラットフォーム上で充実しているため、誰でも簡単にシステムを構築できるように思えます。しかし、それは表面的な理解に過ぎないのではないかと考えています。
AWSは常に進化を続けており、新機能やサービスが次々と追加されています。それを受けていわゆるベストプラクティス自体が変わることも多いです。さらにベストプラクティスは、その文字面だけを捉えて真面目に実現しようとすると、様々なコストがかさみ、とても「ベスト」とは言えない状況に陥ることがあります。
次から、以下2点に関してもう少し深堀していきたいと思います
- AWSの変化の速さ
- ベストプラクティスの実装の難しさ
AWSの変化の速さ
具体的な例をもとにどのくらいAWSの変化が起きているかを示してみたいと思います。
AWSが公開しているAWS ソリューション構成例 - コンテナを利用した Web サービスを例にとります。これは2024/3/6時点の情報をもとに、その時点でベストと思われる構成で組まれているものだと思われます。
この構成を例にとって、2024/3/6以降に発表されたサービスアップデートを取り入れるとどんな改善ができるかを見ていきましょう。なお上記の「コンテナを利用した Web サービス」の構成例には、CI/CDパイプラインの費用が含まれていません。現在のWebシステムの運用には継続的なデプロイが不可欠であり、CI/CDパイプラインの構築もシステム全体のコストを考える上で重要な要素となるため、AWS ソリューション構成例 - AWS Code サービス群を活用した CI/CDの費用も含めて、料金システム全体で下表のAWS利用料がかかっていると想定します。
| 構成 | 月額料金 |
|---|---|
| コンテナを使ったWebシステム | 1236.69 ドル |
| CI/CDパイプライン | 24.25 ドル |
| 合計 | 1260.94 ドル |
AWS利用料の削減に効果のあるアップデート
この構成に対して、AWS利用料削減の効果があると考えられるアップデートは下記3つが考えられます。
- AWS CodeBuild が 3 つの新しい ARM ベースのコンピューティングタイプのサポートを開始（2024/8/5発表）： より安価なARMベースのインスタンスを利用可能
- Amazon ElastiCache for Valkeyの開始方法（2024/10/8発表）： Redis互換の新しいキャッシュエンジンの提供
- Amazon RDS for PostgreSQL、Amazon RDS for MySQL、Amazon RDS for MariaDB が M8g および R8g のデータベースインスタンスをサポート開始（2024/11/26発表）： より高性能なインスタンスを利用可能
これらのアップデートを適用した場合、具体的にどのくらいコストが削減できるのか、以下の表で比較してみましょう。
| サービス | アップデート前 | アップデート後 | コスト削減効果 | 備考 |
|---|---|---|---|---|
| AWS CodeBuild | general1.small | arm1.small | 2.0625 ドル | 2,750分/月の実行時間の場合 |
| Amazon RDS for MySQL | db.m6i.large | db.m7g.large | 1.46 ドル | マルチAZ（1つのスタンバイ）で比較 |
| Amazon ElastiCache | cache.r7g.large(Redis) | cache.r7g.large(Valkey) | 76.796 ドル | 2ノードで比較 |
| 合計 | 80.3185 ドル | 約6%の利用料削減 |
注記:
- 上記はあくまで一例であり、リージョンや使用状況によってコスト削減効果は異なります。上記は本記事執筆時点の東京リージョンの価格で算出しています。
- ARM/Gravitonプロセッサーの変更やValkeyの採用は、アプリケーションの互換性を確認する必要があります。
サービスアップデートを取り込むことで、わずかではありますが、AWS利用料削減の効果が得られました。約6%と少額には見える削減効果ではありますが、複数の環境面を構築するケースも多いかと思いますので、総額としては馬鹿にならない金額となるケースも出てくると思います。過去に実施した類似案件の構成を踏襲してしまうと、上記のようなコスト削減効果を享受できず、AWS利用料の面で「ベスト」の構成は取れない可能性がでてきてしまいますね。
開発・運用体験の向上（工数の削減）に効果のあるアップデート
そのほかにもこの構成例のようなコンテナベースのWebアプリケーションの開発・運用にとって、開発・運用体験を向上させ、結果として工数削減に寄与できるアップデートも数多く発表されました。ここでは以下4つを紹介したいと思います。
-
Amazon Q Developer で AWS リソースについてのチャットの一般提供を開始（2024/7/11発表）
この構成では、様々なAWSサービス（ECS, RDS, Load Balancerなど）を組み合わせる必要があるため、各サービスの設定や連携に関する知識が求められるかと思います。どのように構成を組めばよいのかの調査に時間を要することもあるとは思うのですが、Amazon Q Developerを使えば、構成に関する疑問点をチャットでの解決を支援できます。
この構成へのメリット: ECS, RDS, Load Balancerなどの設定に関する疑問を即座に解決、構築や学習コストの削減 -
Amazon ECS がタスクを再起動せずにコンテナを再起動する機能を提供（2024/8/15発表）
この構成では、ECS Fargateを利用してコンテナを運用するため、コンテナのトラブルシューティング時の対応を迅速にすることは重要になるかと思います。このアップデートにより、コンテナに問題が発生した場合でも、サービス全体を停止することなく、速やかに復旧できる可能性があります。
この構成へのメリット: アプリケーションの可用性向上、ダウンタイムの最小化 -
Amazon GuardDuty を使用した Amazon S3 に新しいオブジェクトをアップロードする際にマルウェアを検出（2024/6/11発表）
この構成で、もしユーザーからのファイルアップロードをS3に受け付ける機能がある場合、S3へアップロードされたファイルにマルウェアが含まれていないかチェックすることが求められる可能性があります。GuardDutyのこのアップデートにより、S3にアップロードされたオブジェクトを自動的にスキャンし、マルウェアを検出できるため、セキュリティリスクを軽減できます。このアップデートがなければ、別途、S3 Event Notifications と Lambda関数、アンチウイルスソフトなどを組み合わせた独自のマルウェアスキャンシステムを構築する必要があり、構築・運用工数やAWS利用料が別途発生してしまうかと思います。
この構成へのメリット: 悪意のあるファイルによる被害を未然に防止、セキュリティレベルの向上 -
Amazon CloudFront が VPC オリジンを発表（2024/11/20発表）
この構成ではCloudFrontの配下にALBを配置する構成となっており、その配置先もパブリックサブネットとなっておりますが、このアップデートにより、プライベートサブネットに配置されたALBを指定し、CloudFrontからの通信のみを許可するような構成も取れるようになりました。これ以前はパブリックサブネットに配置されたALBへのユーザーからの直接アクセスを防ぐためには、CloudFront用のマネージドプレプリフィックスの利用などが必要でしたが、その要件をシンプルに実現することができるようになりました。これはアーキテクチャ自体に影響を及ぼす大きなアップデートだったかと思います。
この構成へのメリット: アクセス制限の実装のシンプル化、セキュリティレベルの向上
これらのアップデートは、ほんの一例ですが、最新アップデートを取り入れることで、システム開発・運用体験を大幅に向上させられるはずです。
ベストプラクティスの実装の難しさ
いくつかのベストプラクティスについて、実案件での実装に落とし込む難しさについて、説明したいと思います。
まずは最小特権のアクセスを付与するというベストプラクティスから考えてみます。このベストプラクティスでは、まずはAWSのマネージドポリシーからはじめて、アクセス状況を見ながら、必要最低限の権限（IAMアクション）に絞っていくことが推奨されています。理想的にはその通りなのですが、これを厳密に適用すると、多数の個別IAMポリシーが作成され、非常に運用負荷が高くなり、結果として適切なアクセスコントロールがされないまま放置されるというケースにも陥りがちです。実際の現場では、社内のセキュリティルールに照らし合わせて、絶対に許容されない操作（例えば情報持ち出しにつながるような操作）のみを拒否するブラックリスト形式でポリシー設計を行うことが多いかと思います。
続いて脆弱性管理を実行するというベストプラクティスについて考えてみます。このベストプラクティスではOSのパッチを常に最新化しておくことなどが触れられており、AWS Systems Manager Patch ManagerやEC2 Image Builder等を使って実現することが書かれています。ですが、実案件ではどのような種類のパッチを適用対象とするのか、システムに影響を与えないようにパッチ適用をする方法などを定めるパッチ戦略を検討する必要があります。これはシステムにおける負荷の特性や環境面の持ち方などによって定まってくるもので、一律に決められるものではなく、ビジネス要件に対する理解や過去の実績が実装に大きく影響してくるものだと考えます。
最後に非準拠リソースの修復を開始するというベストプラクティスについて考えてみます。このベストプラクティスでは、AWSリソースが適切な設定値となっているかを常に確認し、必要に応じて自動で設定値の修復をするべきであると書かれています。確かに不適切な設定値を検出することは重要なのですが、それと同じくらいにそういった違反がきちんと修正されていることが重要になってきます。実案件ではこの修正を行うまでの管理をどのような仕組みで実現するかを検討するのに時間のかかるケースが多いです。どのようなチケット管理システムで違反を管理し、誰が責任をもって修正を行うのかの役割分担やその合意など、AWS以外の要素での調整が多く、技術力とはまた別の能力を求められるかと思います。
AWSから数多くのベストプラクティスが提示されていますが、知識として知っているだけでは不十分な場合があります。現場の状況を踏まえた上で、真に「ベスト」な選択肢を選ぶためには、技術力だけでなく、総合的な判断力が求められる領域だと言えるでしょう。
まとめ
本記事では、「AWSの変化の速さ」と「ベストプラクティスの実装の難しさ」という観点から、AWSを用いたシステム開発のコモディティ化について考察しました。確かに、単に動くシステムを作るだけであれば容易になってきているかもしれません。しかし、最適な構成で、かつ機能する運用を実現するためには、依然として深い知識や経験が不可欠です。個人的には、AWSを用いたシステム開発は決してコモディティ化しているとは言えないと感じています。
仲間募集中です！
NTTデータ クラウド&データセンタ事業部では、以下の職種を募集しています。
- プライベートクラウドコンサル/エンジニア
- デジタルワークスペース構築／新規ソリューション開発におけるプロジェクトリーダー
- IT基盤(パブリッククラウド、プライベートクラウド)エンジニア
- パブリッククラウド/プライベートクラウドを用いた大規模プロジェクトをリードするインフラエンジニア