小規模な受託開発におけるAWSインフラ環境～工数削減のポイントとセキュリティ

小規模な受託開発におけるAWS活用の勘所　第1回

　本連載では、比較的「小規模」な「受託」開発を実施する際のAWS活用の勘所を、実際の開発現場での経験を元に紹介します。大規模な開発では当てはまらない部分もあると思いますが、可能な限りインフラ関連の工数を少なくし、効率的に開発を実施するために、最低限抑えておく実務上役立つ点について、解説します。本記事では、小規模なフルスクラッチの業務システムをビジネスとし、開発を実施する際に参考となるAWSのアーキテクチャや工数のかかる工程、留意すべきセキュリティに関するポイントを紹介します。

はじめに

　比較的小規模なフルスクラッチのシステム開発（1〜20人月程度）を受託するビジネスとする場合、AWS上に「多層アプリケーション（Web層、AP層、DB層）に即したインフラ環境を構築する」ことが多いと思います。

多層アプリケーションの構成例

　このような構成をシステム毎、顧客毎に構築することになりますが、AWSで構築する場合、以下にあげるような状況になることも多いかと思います。

• 利用するAWSサービスは最新のものというより、比較的ベーシックな内容が多い。
• 一つ一つの案件の規模はさほど大きくないため、多くのお客様のAWSアカウントを作成し、それぞれにシステムを構築する必要がある。
• 結果、インフラの構成は大きく変わらないが繰り返し作業が発生する。

　また、開発会社の規模や体制によりますが、以下のような状況に陥っている方もいらっしゃるかもしれません。

• フロントエンジニア、サーバサイドエンジニアは多くアサインできるが、インフラ専門の技術者をアサインできない。
• とはいえ、開発時、リリース時、運用時のインフラ関連のトラブルは発生させたくない。
• 多くのお客様のAWSアカウントを管理する際、セキュリティをどのように考えるのがいいのか。
• クラウドが当たり前のプラットフォームとなり、ハードウェアのEoS（End of Sales）／EoL（End of Life）によるリプレースの機会がなくなり、サーバ関連のソフトウェアアップデートをどうべきか。
• 昔のオンプレミスやホスティング感覚で、一つのサーバに色々なサービスを載せたら、にっちもさっちもいかなくなった。

　繰り返し作業を極力抑止し、汎用的で工数のかかる工程をいかに削減するか、がシステム会社の事業を継続的なものとし、競争力を確保していくために重要となります。

　それらの問題に対する「現実的な」アプローチを紹介していきます。

対象読者

• AWSを業務で使用しはじめたが、どのように業務の軌道に乗せるか模索している方
• AWS利用をスモールスタートし、徐々にAWSにシフトしていきたい方
• AWSのベストプラクティスを学習しているが、実際に業務として使用していく際のアプローチを考えている方
• 今後AWSの利用を考えているが、サービスが多すぎて、何を使えばいいか迷っている方

AWSで業務システムを構築する際のよくあるアーキテクチャ

　当社で、AWSを利用した業務システムを構築する際に、多くの案件で構築するAWS上でのアーキテクチャをご紹介します。

よくあるAWS上でのアーキテクチャ

　AWSをあまり利用したことがない方向けに、各AWSのサービスをどのように利用しているのかを説明します。

Route53

　言わずとしれたDNSサービスです。

ACM（AWS Certificate Manager）

　SSL／TLS証明書管理のサービスです。無料でDV（ドメイン検証）のSSL／TLS証明書を発行できます（既存SSL／TLS証明書のインポートも可能）。SSL／TLS証明書はELB（Application Load Balancer／Classic）、CloudFrontで利用が可能です。

　2017年11月より、証明書発行時の認証をDNS認証を通じて実施することができるようになり、クローズドなシステムにおける自動更新の利便性が非常に高まりました。

ELB（Elastic Load Balancer）

　言わずとしれたロードバランサです。HTTP／HTTPSでサービスを公開する際、ほぼ必須の存在です。

EC2

　言わずとしれた仮想サーバです。Web／APサーバとしても使用しますが、ビルド／デプロイ用サーバ、メールサーバとしてもよく使用します。

AutoScaling

　水平スケーリングを実現するため、CloudWatch AlarmやCodeDeployと連携し、EC2インスタンス数を必要数以上に保ちます。

RDS

　言わずとしれたリレーショナル・データベースサービスです。DB層を独立して管理し、管理コストを減らすためにEC2から切り出します。

CloudFront

　CDNサービスです。S3バケット等をオリジンとして、静的なファイルやサイズの大きいファイルなどを配信する際に使用します。アクセス制御が必要な場合は、署名付きURL／Cookieを使用して認証・認可された場合のみ参照可能とします。

S3

　オブジェクトストレージです。EC2をステートレスとして、オートスケールさせる際には、永続的なファイル置き場として必須の存在です。EC2へ最新のアプリケーションリビジョンをデプロイする際のファイル置き場としても利用しています。

CodeDeploy

　アプリケーションをデプロイする際に、サービスを止めずにデプロイを実現するローリングアップデートのために使用しています。

CloudWatch

　各種リソースの監視やアラームをトリガーとしたアクション（オートスケール等）に使用します。

　今までの説明をまとめると、ここで説明している「よくあるアーキテクチャ」とは、以下を実現する最小限の構成です。

• EC2、RDSを利用した多層アプリケーションの実装
• EC2をステートレスとし、オートスケールを可能に
• 静的、ファイルを配信するCDN
• デプロイ時にサービスを止めないローリングアップデート

　もちろん、要件によっては他のAWSサービスを連携させ、よりリッチな構成にすることも多々ありますが、上記のアーキテクチャはほぼどのような業務システムを開発する際にも登場します。

　比較的「小規模」なフルスクラッチの業務システムにおいては、このアーキテクチャでおおよその要件を賄うことができるケースがほとんどです。