athome-developer’s blog

不動産情報サービスのアットホームの開発者が発信するブログ

トップ > AWS > 不動産情報サイト アットホームをAWS化しました

不動産情報サイト アットホームをAWS化しました

AWS

こんにちは、情報システム部の白石です。

2016年12月にB向けシステムのグループから、C向けシステムのグループに異動し、初めてAWSを使う案件を進めていました。

はじめは静的リソース配信のCloudFront化。次にインプレッションログをサーバレスの仕組みで収集する案件。 そして2017年2月から不動産情報サイト アットホームをAWSへ移行する案件を開始しました。 3人から始めて最後は10人程度のメンバーで、皆AWSはほぼ初心者状態でのスタートでした。

途中、数回案件の仕切り直しがあり、サイトのすべてではなく2段階に分けて移行させることになり、 2018年9月に不動産情報サイト アットホームのフロント部分であるWeb、AP、検索DBをAWSへ移行することができました。

私は主にネットワーク、インフラ設計・構築と自動デプロイツールの設計・作成を行いました。

  f:id:ts05760:20181120230624p:plain  

フロント部分のメインサーバはオンプレでは30台ありましたが、AWS化後は14台と半分以下に削減できました。

今回のAWS化のミッション

  • コスト削減
  • 安全に素早くリリースできるようにする(BlueGreenデプロイメント)
  • インフラ構築・変更の速度向上と柔軟に増減可能にする
  • セキュリティーの見直し
  • パフォーマンス向上の為のドメイン一本化

大きなものを抜粋しました。

安全に素早くリリースできるようツールを自作

今回はミッションの一つ「安全に素早くリリースする」のために、独自に作りこんだBlueGreenデプロイツール(※以降、BGツールとする)の話をします。

これまでのリリース

以下のように複雑な作業が必要でした。

WebやAP、検索DBをA面、B面と分けて、片面をLBから切り離したのちにアプリをリリースしLBに戻す。

それをWebとAPそれぞれ行う。

これらを慣れたリリース担当者が約半日がかりで行っていました。また新旧アプリが混在する時間も10分程度存在していました。

AWSでのリリース

Web、AP、検索DBを新たに30分程度かけて作成し、Webの手前のALBの向き先を切り替えることで1秒以内程度で切り替えを可能にしました。

BlueGreenデプロイメントといってもBlue面とGreen面を交互に使うわけではなく、BlueGreenIDというを日付と時刻を元に発番したIDを使い、リリースの度に新しい面を作成し、リリース終了後ロールバックしないと判断した後に古い面は削除します。Immutableデプロイメントという概念に近いです。

リリースのためだけでなく、検索DBの夜間データ洗い替えにも同じBGツールを自動モードで使っています。

日中は全自動ではなくGreen面までできたところでGreen面で動作確認を行ったのち手動で切り替えます。

BGツールは慣れているシェルスクリプトで作成し、リソースは削除する必要もあるため、基本的にCloudFormationで作成し、AWS CLI*1を駆使して制御しています。

BGツールで作るリソースは以下の通り

  • 検索DB用EC2インスタンス(AZ*2毎に合計2台以上)
  • APサーバが検索DBを参照するためのRoute53プライベートホストゾーンのレコード(AZ毎に合計2つ)
  • APサーバをバランシングするためのNLB(AZ毎に合計2つ)
  • Webサーバ用のAutoScalingGroup
  • APサーバ用のAutoScalingGroup(AZ毎に合計2つ)
  • AutoScalingGroupでインスタンス作成失敗を監視・修正するSNSとLambda

  f:id:ts05760:20181121142435p:plain  

上の図の緑の太い実線の矢印に流していたリクエストを、緑の太い点線の矢印に向けなおすことでデプロイを行っています。

メリット

  • スクリプトを実行するだけの全自動なので人手が必要ない
  • リリース直後不具合が見つかってもすぐに前の面に切り戻しができる
  • 自作したのでテスト環境では台数を減らしたりインスタンスタイプを下げたりするなど柔軟に対応できる

デメリット

  • 一時的に2倍のリソースが必要になり若干コストがかかる
  • 自作したのでスクリプトが複雑になる

はまった問題

テスト中やリリース直前にいくつか問題が発覚しました(のちに修正しています)。

APサーバ用のLBにALBを採用していたがALBだと暖機が必要だった

常に暖機申請する必要があったため、暖機が必要ないNLBを採用しました。

インスタンスのキャパシティー不足

構築してテストをしているうちに、EC2インスタンスがAZのキャパシティー不足で起動できない現象に数回遭遇したため、キャパシティー不足の場合はインスタンスタイプを変更して再作成するという仕組みも組み込んでいます。

APサーバから検索DBサーバへはDNSで名前解決しているがEC2のDNS サーバーへ送信できるパケット数上限(1024パケット/秒)に引っかかった

性能テスト中にAPサーバで詰まりが発生して発覚しました。APサーバでDNSをキャッシュするようにしました。

切り替えに時間がかかる、かつ503エラーがでる

AutoScalingGroupのターゲットグループを付け替えるという方法で切り替えを行っていましたが、AWS CLIでターゲットグループのアタッチをした直後にデタッチすると、アタッチに時間がかかり先にデタッチされてしまうことがあり503エラーが出ていました。それを防ぐためにアタッチ完了を待ってからデタッチすると2分程度新旧混在してしまいました。

それを解決するためALBのリスナーのデフォルトルールを更新するという方法にすることで瞬時に切り替えが可能になりました。

まとめ

不動産情報サイト アットホームのAWS化の中の、 BlueGreenデプロイメント用の自作ツールの紹介とメリット、デメリットやはまった問題とその解決策について書きました。

 

弊社ではエンジニアを募集しています。 興味がある方は下記からエントリーお願いします。 athome-inc.jp

*1:AWS コマンドラインインターフェイス

*2:アベイラビリティーゾーン