LAMP のシステムを Azure の PaaS に移行しました

こんにちは。Azure系エンジニアの秋山です。
今回は LAMP のシステムを AWS から Azure に移行したことについて書きます。

移行前のアーキテクチャ

システムはオーソドックスな LAMP 構成です。

aws-structure

以下のとおり、よくある構成ですね。

  • DNS(Route53)
  • ロードバランサー(ELB)
  • Webサーバー(EC2)
  • バッチサーバー(EC2)
  • キャッシュ(ElastiCache)
  • データベース(RDS)

問題点

何のために移行するのか、解消したい問題点は以下のとおりでした。

  • Web サーバーがオーバースペックになっている
  • Production へのデプロイは開発環境のEC2をAMIコピーして行う
    また開発環境が1台のみでソースコードのバージョン管理がされていない
  • 外注で制作したが社内で誰も手を入れられていない
  • Azure のメンバが面倒見ているサービスが AWS で動いている

移行後のアーキテクチャ

このシステムは自社で運用していますが、ユーザ数がそこまで多くなく、サービスダウン時の影響の少なさから、現時点でプレビューである WebApp on LinuxAzure Database for MySQL を採用しています。
これによって IaaS を排除した PaaS のみの構成となりました。

2017/09/12追記: WebApp on Linux は Web Apps for Containers に名前を変えて GA しました。

azure-structure

  • 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 でアラートを出すようにしています。

notify-slack

まだプレビューのサービスを使うには、多少のダウンタイムは覚悟しなければなりませんね。。

どうなったか

問題点に挙げたことを一つずつ振り返ってみます。

Web サーバーのスケーリング

問題点

Web サーバーがオーバースペックになっている。

結果

WebApp on Linux は Windows 版同様に柔軟なスケーリングを行うことができます。
手軽に必要最低限のスペックまで落とせるようになりました。

EC2 でもスケールダウンすればいいだけなので、できなかったというわけではありませんが、よりやりやすくなりました。

デプロイフロー

問題点

Production へのデプロイは開発環境のEC2をAMIコピーして行う。

結果

以前はソースコードのバージョン管理すらできていませんでしたが、今は GitHub への push から一連のデプロイフローによってステージング環境が更新されるようになりました。
問題がなければスワップして完了です。

deployflow

メンテナ

問題点

外注で制作したが社内で誰も手を入れられていない。

結果

今回の移行作業によって、少なくとも私自身は手を入れられる状況になりました。
また、この記事を書くことによって、インフラ構成やデプロイフローをドキュメントとして残すことにもつながりました。
弊社のプログラマならば問題ないでしょう。

パブリッククラウド選定

問題点

Azure のメンバが面倒見ているサービスが AWS で動いている。

結果

弊社では複数のパブリッククラウドベンダーとお付き合いさせていただいております。
今回のシステムは Azure のメンバが管理していたため、移行に伴い、検証している Azure の最新技術を試す場として活用できるようになりました。

最後に

Azure に限らず、パブリッククラウドのサービスの進化は非常に早いです。
サービスを適切に組み合わせることで最低限の監視で済ませ、よりより開発環境を現場に適用できます。
開発にフォーカスできる環境をご希望の方は、お気軽にご相談ください

LAMP環境のAzure PaaS移行支援 くらまね for Azure

おすすめ記事