sre_techmeetup_moriya.pdf

私の所属するチームでは AWS EC2 上でサーバーサイドの運用を行ってきました。サービスリリース当初からの様々な改善の積み重ねの結果、近頃はインフラ障害も少なくなり、安定した運用が実現しています。しかし既存インフラには様々な技術的負債が蓄積されており、メンテナンスし辛い環境でした。 そこでサーバーチームは既存インフラを設計から見直し、開発環境を刷新する決断をしたのです。 本資料では既存インフラが抱えていた問題点やそれをいかに刷新して解決していったか、また日々作業している現場のメンバーへの負担をできるだけ抑えつつ移行を実現した経緯を解説します。

Transcript

1. 開発環境インフラ⼤刷新 ~幸せなインフラ運⽤を⽬指して~ 2019.5.22 yappli site Reliability Engineering Meetup 株式会社アカツキ サーバーエンジニア 守屋邦昭
2. ⾃⼰紹介 守屋邦昭(Moriya Kuniaki) 株式会社アカツキに新卒で⼊社して3年⽬ 運⽤中ゲームタイトルのインフラ構築・運⽤(AWS, GCP)や サーバーサイドアプリケーション開発(Rails)を担当 Docker や k8s といったコンテナ関係に興味がある 趣味はギター、カラオケ、Switch、お笑い動画漁り
3. 経緯 • リリースして数年が経つモバイルゲームのサーバーサイド • 最近はインフラ障害も少なく、安定した運⽤が実現している • 既存の開発環境には多くの技術的負債が蓄積されており、 メンテナンスが⾮常に⾟かった 安定しているがメンテナンスコストが⾼いインフラ
4. 本セッションの要点 幸せな運⽤を⽬指してインフラの⼀⼤刷新を⾏った話をします • 既存開発環境インフラが抱えていた問題とそれに対する解決策 • ⽇々作業している現場のメンバーへの負担を抑えたインフラ移⾏
5. • 既存開発環境のインフラ構成 • 既存開発環境の問題点 • 移⾏を⾏う上での課題 • 解決策 • 新規インフラ構成 • 移⾏の流れ • まとめ アジェンダ
6. 既存開発環境: インフラ構成 ELB Application Server Log Aggregator RDS Master & User log Memcached Redis ElastiCache S3 CloudFront S3 Development 01 運⽤開始して数年経つモバイルゲームのサーバサイド • 本番・開発環境共に AWS 上に⼿動で構築されてきた • アプリケーションは EC2 上で動作 • マスタ(全ユーザー共通) + ユーザー(ユーザー固有)の2種類の DB + キャッシュに ElastiCache を使⽤ • 複数の開発環境が存在し、エンジニア・QA・運⽤メンバーが 常時接続し、作業している インフラ設定は⼿動 & 複数の環境が存在
7. 既存開発環境: アプリケーション EC2 EC2 上に構築されたサーバーサイドアプリケーション • Ruby on Rails + Nginx を⽤いたゲーム API サーバー • 他にも管理者⽤ツール(Active Admin)やバッチ処理も 同⼀ホスト上で動作 • 構成管理ツール Chef でミドルウェアのインストール等の セットアップを⾃動化 APIサーバー バッチ処理 ランキング集計等 のバッチ処理 管理者⽤ツール アプリケーションサーバーの設定が複雑
8. 既存開発環境: デプロイフロー Application Server Deploy Server RDS Master & User Hubot Server Migration Deploy Hubot command Slack から Hubot コマンドを叩くことで各種タスクを実⾏ 踏み台サーバーを中⼼とした運⽤体制 • デプロイ(Capistrano3)や DB Migration は踏み台サーバー から実⾏ • 他にもマスタデータの Seeding や検証⽤ダミーデータ⽣成 など運⽤・QA 向けに多くのタスク (ほとんどが Rake タス ク)が存在 • Slack から Hubot コマンドを叩くことで⾮エンジニアでも 各種タスクの実⾏が可能
9. 既存開発環境の問題点 • Chef で構成管理はしているが、ミドルウェアのアップデートへの追従が困難 • クレデンシャル・環境変数が dotenv ファイルに記述されて全サーバーに直置き • Chef のレシピや dotenv ファイルを別途メンテナンスしていかなければならない アプリケーションサーバーの設定が複雑 インフラ設定は⼿動 & 複数の環境が存在 • インフラ全体の設定の属⼈化が進⾏ • ゲームの新機能開発では複数のバージョンを並⾏で開発するため、開発環境は複数必要 • 新規環境の構築も⼿動で⾏う必要がある 新規環境の構築や既存環境の設定更新に⾮常に⼿間がかかる
10. 移⾏を⾏う上での課題 踏み台サーバーを中⼼とした運⽤体制 • Hubot コマンドでの運⽤体制を変えると現場の混乱を招く • 下⼿に DB や各種ツールのエンドポイントを変えると現場の混乱を(ry インフラ刷新によって問題を解決しつつ、現場への負担は最⼩化したい 稼働中インフラの移⾏である • たとえ１⽇でも⽌めてしまうと新規開発・運⽤スケジュールに⼤きな影響を与えてしまう
11. 解決策 設定管理をシンプルに ① Docker、ECS への移⾏ ② dotenv ファイルの直置きを⽌める ③ CloudFormation でインフラ全体を再構築 新規環境構築をコマンドで実⾏可能に ④ 既存のインターフェースを変更しない ⽇々作業しているメンバーへの負担を最⼩化
12. 解決策① Docker、ECS への移⾏ • Rails, Nginx, Fluentd 等のアプリケーションを全て Docker コンテナ上で運⽤ • ECS でコンテナの実⾏、管理を実現 (起動タイプは EC2) • DBはコンテナ化するメリットがあまり無い為、従来通りとする • Docker の ENTRYPOINT にスクリプトを挟んで条件分岐させることで、同じイメージから異なる サービスを起動させる Application Server API Server Fluentd Admin Tool Batch サーバー⾃体の構成管理コストが激減 API Server Admin Tool Batch entrypoint.sh
13. 解決策② dotenv ファイルの直置きを⽌める • 各種パラメータを登録するとAPI (AWS CLI) 経由で値を取得できる (RubyのGemもあり) • Dockerコンテナのランタイムで API を叩いて環境変数を展開 System Manager Parameter Store AWS System Manager Parameter Store を導⼊ 各パラメータをAWS上で⼀元管理
14. 解決策③ CloudFormation でインフラ全体を再構築 • ネットワークから全て作り直すことで AWS 上の全リソースをコード管理下に置く • Kumogata2 を導⼊すると Ruby で柔軟な設定の記述が可能となる • ホスト名等の環境毎に異なる情報は環境変数として envfile に記述 • 新規環境の構築時は envfile を追加してコマンド適⽤すればテンプレートに応じて⾃動で リソースが⽣成される envfile の追加 CloudFormation 適⽤ AWS リソース⽣成 新規環境の構築がコマンドで可能に
15. 解決策④ 既存のインターフェースを変更しない • 新 VPC 下にインフラを⽴て直すが、DNS を切り替えることで既存のエンドポイントを変えない ようにする • 踏み台サーバーは従来通り EC2 で設置し、Hubot コマンドも従来通り利⽤できるようにする • 移⾏の際は移⾏前後の環境が共存することになるので Hubot 側で ECS 環境か否かを判断させる 移⾏後も従来通りの運⽤が実現 Application Server Deploy Server ECR RDS Master & User Hubot Server Hubot command ECS Clusters Migration Deploy Image build & push デプロイフロー
16. 解決策④ 踏み台サーバー⾃体の構築コストも最⼩限に Deploy Server Docker run Hubot Server Hubot command 各種 Rake タスクの実⾏はどうするか • 踏み台サーバー上にはデプロイ時にビルドされた各環境の Docker イメージが存在 • Docker コンテナを⼀時的に⽴ち上げて Rake タスクを実⾏ • 踏み台サーバー上に Rails 環境構築をする必要はない Development 01 タスク実⾏ 既存のインターフェースを変更しない
17. 新規インフラ構成 RDS Master & User log Memcached Redis ElastiCache All Servers S3 CloudFront S3 ALB ECS Clusters • アプリケーションは ECS 移⾏、ロードバランサーも ALB に • それ以外のリソースは従来通り • CloudFormation で全リソースの管理が実現
18. 移⾏の流れ 開発 (約2ヶ⽉間) 1. CloudFormation で新規ネットワーク作成 2. Sandbox 環境を構築 3. アプリケーション側の改修(Dockerfile 等) 4. Hubot の改修 & デプロイフロー整備 5. ひたすら動作検証 & 改善 事前準備 1. 現場の各セクションに移⾏スケジュールを周知 2. 移⾏時間を短くする為、S3 内の不要なデータを削除
19. 移⾏の流れ 1. 既存の RDS 、Elaticache 等のリネーム(CloudFormation適⽤時に衝突する為) 2. CloudFormation で新環境⽤のリソース作成 (ECS、RDS、ElastiCache、S3...) 3. S3 データ移⾏ 4. RDS データ移⾏ 5. アプリケーションのデプロイ 6. 動作確認 7. Hubot の切り替え 8. Route53 で DNS 切り替え 1環境辺り4~5時間程度のダウンタイムで移⾏が完了 移⾏開始 (ダウンタイム発⽣)
20. まとめ 稼働中の開発環境にて現場への負担を最⼩化しつつ、インフラ刷新 によって技術的負債の解決を実現した事例について紹介しました ① Docker、ECS への移⾏ ② dotenv ファイルの直置きを⽌める ③ CloudFormation でインフラ全体を再構築 ④ 既存のインターフェースを変更しない 現在は本番環境の移⾏に向けて負荷試験も交えながら準備を進めています
21. ご静聴ありがとうございました！