猫でもわかるWebプログラミングと副業

本業エンジニアリングマネージャー。副業Webエンジニア。Web開発のヒントや、副業、日常生活のことを書きます。

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

もくじ

f:id:yoshiki_utakata:20180129131332j:plain

概要

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

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をまわす
  • ブラックボックスを解消するために地雷を踏み抜いていく

移行で良くなったか?

良くなった

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

移行はスタート地点

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