AWSのDevOpsサービスと当社マネージドサービスを活用したDevOpsの実装②～実装編～

前回の概念編では、DevOpsの概念と、AWSでのDevOpsベストプラクティスであるCI/CDソリューションをご紹介しました。
今回は、実際に当社で担当しましたお客様の、AWSソリューションを活用したDevOpsの実装例についてご紹介します。

柔軟なアプリケーション基盤

当社が担当していましたお客様の事例では、AWSへの移行を検討していたWEBアプリケーションは、即時に変更を求められるリリースが多発していました。

当時、お客様は手動でリリースを行っていたため、

リリースのミスによるサービス停止が発生している
リリース作業の工数が増大している

という課題をお持ちでした。

そのため、AWSにアプリケーションを移行するにあたり、「今後の運用では仕様変更に耐え得る柔軟なアプリケーション基盤を構築したい。」といったご所望がありました。

当社では、お客様のリリース要件に合わせた、DevOpsの実現を検討しました。

AWS CodePipeline/ AWS CodeDeployの利用によるDevOpsの実現

前述のお客様は、アプリケーションのバージョン管理を、既に外部サービスで実施していました。

そのため、AWS移行後では開発環境・ステージング/本番環境と環境を分け、外部サービスと各環境の連携を行い、リリースの自動化をすることでCI/CDを実現出来ました。

①開発用リポジトリよりソースコードをPULL ②改修したソースコードを開発リポジトリにPUSH ③自動的に開発環境へデプロイ ④開発環境にてアプリケーションの正常性を確認 ⑤ソースコードをマスタリポジトリにPUSH ⑥自動的にステージング環境へデプロイ ⑦ステージング環境でアプリケーションの正常性を確認 ⑧自動的にステージング環境と本番環境を入れ替える

また、本番/ステージング環境では、反復可能なデプロイを実現するため、二つのAuto Scaling Group(ASG)を共通のApplication Load Balancer(ALB)配下に紐づけを行いました。このASGは、どちらか一方が本番で、一方がステージング環境の役割を果たすようになっており、リクエストされたホスト名を参照してALBにて振り分けを行っています。アプリケーションのリリースは、S3に付与されているTAGを参照し、ステージング環境を判断しリリースを行います。

ステージング環境で動作確認に問題なければ、ALBの紐づけを変えることで本番環境と入れ替えを行うため、

何度でも切り戻し・リリース可能な本番環境の実装
ステージング環境と本番環境の差異をなくし、リリース作業による事故の防止
リリース作業による工数の削減

といった環境を実現し、ご提供しました。

バージョン管理ソフトウェアにおいて、TAGを参照してリリースするAmazon S3へアプリケーションをアップロード→S3への配置を検知して、CodePipelineを起動し、ステージング環境へリリース→OSのパッチをあてる場合、テンプレートとなるAMIを更新し、ステージング環境で動作確認→動作確認後、本番とステージングの切り替えを実施

DevOps環境の安定した運用

前記事の「AWSのDevOpsサービスと当社マネージドサービスを活用したDevOpsの実装～概念編～」でもご紹介しましたが、DevOpsとは「チーム内で開発と運用が協力し合う組織活動」のことです。

当社は環境を実装するだけではなく、お客様のDevOps運用をサポートするために、月次でお客様との定例ミーティングを行っております。月次の定例ミーティングでは、お客様のご要望をヒアリングしています。その中でお聞きした、ご要望や課題は当社営業と提案SEが連携をとり、解決に向けて取り組むことが出来るマネージドサービスが当社では整っています。

当社のマネージドサービスをDevOps運用に活用することで、お客様のDevOps運用をサポートすることが可能となっています。