『キッ！レガシーだらけのAWS移行大会』のメモ

もくじ

概要

以下の勉強会に参加してきた時のメモ書きです。

https://atnd.org/events/93585atnd.org

以下メモです。

レガシーだらけのAWS移行

課題

もともとオンプレ環境で動いていた。レガシーインフラだった。さらに大量の技術的負債があった。例えば、Cent OSが5系だったりなど。Cent OS 5は2017年3月でサポートが切れるのでなんとかしなければならない。

レガシーインフラとはどういう受胎だったか

• インフラの設定がブラックボックス化。設定当時のドキュメントだけチョット残っている。秘伝のタレ状態。
• 構成変更申請が煩雑で遅い。
• 色々なサービスが乗っている

→AWS移行

どのように移行したのか

ステージング環境から移行した。

しかし様々な問題があった。例えば、リソース不足。いつもの運用をしながら移行作業をする必要があった。

そこで、週2回のAWSデーを設け、その日はAWS移行しかしないなどの策を行った。

マインド

• 小さく素早く始める
• ブラックボックス部分を潰しながら始める
• 技術的追求をしていると終わらない。主目的を忘れない。

技術的な部分

サーバー構成

• サーバーは全てCent OS 5
• アプリケーションはRuby on Rails
• DBはMySQL

AWSではどうするか

• アプリケーションサーバーなどはEC2で
• DBはAurora

設計について

lb→elb/alb用　外部からhttp/httpsのみ許可するなど、必要なポートだけを開ける。（アプリケーションサーバーやDBサーバーなども）

他にも色々問題があった

• 複数のアプリケーションが1台のサーバーが動いている
• jobサーバーがいるのにアプリケーションサーバーでもcronとかが動いている

などなど...

• 1アプリケーション1サーバーにする
• jobサーバーでのみcronを動かす

ようにする。

Alertやmonitoringはオンプレの時はHinemosにしていたが、fluentdなんかを使うようにした。

構成管理

インフラ設計書は設計当時のものが残っているだけで、ブラックボックス化。

→HashiCorpのTerraform で Infrastructure as Code 化した。

Terraform

つらみ

• Version UP が多いので追いつくのが大変
• planとapplyで結果が異なる時がある

よさ

• 簡単なのでとっつきやすい
• AWSで手動でポチポチするのはつらいがそれから解放される

AES ALB

• アプリケーションロードバランサ
• Amazon ECS との親和性が高い

nginx as reverse proxy

• 顧客ごとにアプリケーション・サーバーを振り分けるiRuneをこちらに持たせる
  • 定義が複雑なのでALBだと辛い

Amazon ECS

• サービスを安定的・継続的に提供するうえで魅力的

つらみ

• Auto Scalingの勘所が掴みづらい
  • コンテナとインスタンスをスケールしてやる必要があり難しい
• kubernetesを使っていたい

よさ

• Managed Service への安心感
• 一旦慣れると作業としてはコンテナの中に集中できるので、あまりインフラのことを気にしなくて良くなる。

データベース

レプリカが機能していないこともあり、それに気づかないこともあった

→Amazon Aurora に

Amazon Aurora

• 機能単位でDBを整理して、クラスタを構築。
• 最初は Amazon RDS MySQL 5.6 だったが、Aurora監査ログ機能に対応したため、急遽Auroraに変更。
• つらみがあまりなく非常に良い。メンテナンスもすぐ終わる。

監視

• もともとはHinemosを使っていた。
• オオカミ少年化していた。需要なアラートが埋もれてしまう。
• GUIベースの設定変更がめんどくさい。
• Windows Serverで動かす必要がある。

Mackerel, Fluentd, Slack通知

• プロセス監視はMackerelを利用
• log監視はFluentD
• 何かあればSlackに通知

つらみ

• 設定みするとSlackがエラーで埋もれる
• Mackerelのec2インスタンスのintegration（サーバーを勝手に監視対象に入れてくるやつ）が、ステージング環境にも反応してしまったりするので、途中で切った。

よさ

• 設定がファイルベースで管理が楽

ストレージ

• Amaon EFS が東京リージョン未対応なのでAmazon S3 + goodfysを利用

goodfys

Amazon S3をNFSとして扱えるgo制のアプリケーション

つらみ

• goofysのドキュメント少なすぎ

よさ

• 軽い

移行どうしたか

とりあえずstaging環境を立てて検証した（環境構築1ヶ月ほど）

DNS

社内DNSからAWS Route53に

苦労点

• Route 53 弄るのが簡単
• オンプレDNSキャッシュサーバーにオンプレ環境のDNSが残ってたり...

メールサーバー

• 時前のメールサーバーを使っていた
• AWS SES や SendGrid を検討
• ガラケーへのメール送信やバウンス周りの不安が
• 結局EC2に乗せた

移行後、ステージング環境は送信制限を設けた。ガラケーの送信テストは部署内で持っている人

DBの移行

• ダンプが50GBがある。
• メンテ8時間とっていて、その中DBに使えるのは4時間
• 間に合わない

どうするか

• xtrababckup
  • AWS推奨
  • オンプレでxtrabackupが使えなかった
• レプリケーション
  • MySQLのバージョンが違いすぎたりして無理
• 差分バックアップ
  • これを採用
  • 予めフルダンプをして突っ込んでおいて、メンテでは差分だけをバックアップする

段階的な移行

• 一度に移行するのはつらいのだ段階移行
• 一部のお客様だけAWS みたいな
• オンプレとAWSを並行して面倒を見るのは結構大変

移行方法

• まずはRoute53とnginxリバースプロキシを移行
• リバースプロキシで一部お客様をAWSへ向ける
• 移行失敗時の切り戻しラインはしっかり決めていたため、1回目失敗時の切り戻しはスムーズにできた

移行後

• 想定以上のスピードでサーバーが増えた→サーバーの構成管理に課題が出てきた
• AWSのセキュリティチェックをしようということになった

構成管理

user-data（shell）で構築していたが、移行後に修正したものの差分がではじめた。

そこで、capstranoやansibleを使って構成管理を見直す。

セキュリティ

• guard duty の有効化など

全体のまとめ

マインドについて

• チームプレイにするのが重要
• 技術的追求ばかりせず、主目的を忘れないように
• とりあえず環境を作ってPDCAをまわす
• ブラックボックスを解消するために地雷を踏み抜いていく

移行で良くなったか？

良くなった

• インフラのブラックボックス化解消
• インフラ構成変更が早くなった
• 不具合調査もチーム内で完結！

移行はスタート地点

• クラウド＝スピード感をもってサービスを改善するための土台