こんにちは。Azure系エンジニアの秋山です。 今回は LAMP のシステムを AWS から Azure に移行したことについて書きます。
移行前のアーキテクチャ
システムはオーソドックスな LAMP 構成です。
以下のとおり、よくある構成ですね。
- DNS(Route53)
- ロードバランサー(ELB)
- Webサーバー(EC2)
- バッチサーバー(EC2)
- キャッシュ(ElastiCache)
- データベース(RDS)
問題点
何のために移行するのか、解消したい問題点は以下のとおりでした。
- Web サーバーがオーバースペックになっている
- Production へのデプロイは開発環境のEC2をAMIコピーして行う また開発環境が1台のみでソースコードのバージョン管理がされていない
- 外注で制作したが社内で誰も手を入れられていない
- Azure のメンバが面倒見ているサービスが AWS で動いている
移行後のアーキテクチャ
このシステムは自社で運用していますが、ユーザ数がそこまで多くなく、サービスダウン時の影響の少なさから、現時点でプレビューである WebApp on Linux や Azure Database for MySQL を採用しています。 これによって IaaS を排除した PaaS のみの構成となりました。
2017/09/12追記: WebApp on Linux は Web Apps for Containers に名前を変えて GA しました。
- DNS(AzureDNS)
- Webサーバー(WebApp on Linux)
- バッチサーバー(Logic App)
- キャッシュ(Redis)
- データベース(AzureDatabase for MySQL)
- サービス監視(Application Insight)
Webリクエストによって発火するバッチ処理がありましたが、EC2 の cron から Logic App に乗せ換えたことで IaaS を排除し、低コスト化しています。 Application Insight の可用性テストでサービス監視し、Logic App に WebHook で流して Slack でアラートを出すようにしています。
まだプレビューのサービスを使うには、多少のダウンタイムは覚悟しなければなりませんね。。
どうなったか
問題点に挙げたことを一つずつ振り返ってみます。
Web サーバーのスケーリング
問題点
Web サーバーがオーバースペックになっている。
結果
WebApp on Linux は Windows 版同様に柔軟なスケーリングを行うことができます。 手軽に必要最低限のスペックまで落とせるようになりました。
EC2 でもスケールダウンすればいいだけなので、できなかったというわけではありませんが、よりやりやすくなりました。
デプロイフロー
問題点
Production へのデプロイは開発環境のEC2をAMIコピーして行う。
結果
以前はソースコードのバージョン管理すらできていませんでしたが、今は GitHub への push から一連のデプロイフローによってステージング環境が更新されるようになりました。 問題がなければスワップして完了です。
メンテナンス
問題点
外注で制作したが社内で誰も手を入れられていない。
結果
今回の移行作業によって、少なくとも私自身は手を入れられる状況になりました。 また、この記事を書くことによって、インフラ構成やデプロイフローをドキュメントとして残すことにもつながりました。 弊社のプログラマならば問題ないでしょう。
パブリッククラウド選定
問題点
Azure のメンバが面倒見ているサービスが AWS で動いている。
結果
弊社では複数のパブリッククラウドベンダーとお付き合いさせていただいております。 今回のシステムは Azure のメンバが管理していたため、移行に伴い、検証している Azure の最新技術を試す場として活用できるようになりました。
最後に
Azure に限らず、パブリッククラウドのサービスの進化は非常に早いです。 サービスを適切に組み合わせることで最低限の監視で済ませ、よりより開発環境を現場に適用できます。 開発にフォーカスできる環境をご希望の方は、お気軽にご相談ください。
