「株式会社インテリジェンス」 さんでのオンプレからAWSの導入事例のセッションの中で、
コンテナ化や infrastructure as code の話が出てきて面白かったので記します。
弊社もこの辺の整備は挑戦していきたい。

課題

• 2016年4月以前
  • レガシーインフラ!
  • グループ共通のオンプレ基盤
  • 子会社に随時スケール依頼/調査依頼投げる
  • スケールしない
  • 秘伝のタレ
  • ブラックボックス
  • 積み上がることで新しいサービスを始められるスピードが逆に下がっていく
• 移行作業
  • DevOpsチーム4名
  • ぽんぽん依頼投げられて集中できない
  • エンジニアだけでなく会社としての協力
  • 移行デーを週に2日設けてそれに集中する
  • 2016年11月に移行開始 => 2017年4月完了

アーキテクチャ

• ALB , ECSによるnginxコンテナ , マカレル、等々。

Terraformによるプロビジョニングを導入

• 古参メンバーの秘伝のタレをterafform化。
• infrastructure as code.
• terraformを導入して困ったところは一部あった
  • dry run と実際のプロビジョニングとの結果が違うことがあった
  • 当時はアップデートが頻繁だった

ALB & コンテナ

• ALBとECSとの親和性が良い
• nginxコンテナ
• なせコンテナにしたか?
  • 依存関係が明確に分離。
  • 開発と本番の環境が一致する。
  • スケールするのが簡単
• blue green developmentがすごい
  • 3つのコマンドで完了
  • ALBにつながっているバージョン1のコンテナが徐々に減らされていって、バージョン2のコンテナが徐々にぶら下がっていく
  • 戻すときも同じ作業なので簡単

Aurora

• はじめは MySQL on RDS にしようとしていたが、性能と監査ログの機能からAuroraに決めた
• 移行にかんしてはAWSのサポートにどんどん聞く

監視

• プロセス監視 => mackerel
• ログ監視 => fluentd
• アラートをSlackに飛ばす

NFS

S3 + goofys に移行した
* とてもいいことがあったわけでもないのでEFS早くきてほしい

小さく素早く始める

• とにかく素早くstagng構築
• 2段階で移行
  • 旧環境と新環境で並列稼働させる

移行して良かったか?

YES

• ブラックボックスが全てプロビジョニングコードに落とし込まれた
• ハンドリングが可能
• 全てが透明
• 市場変化に楽しく対応できるようになる