Skip to content

Latest commit

 

History

History
364 lines (252 loc) · 10.5 KB

slide.md

File metadata and controls

364 lines (252 loc) · 10.5 KB

僕らのAWS移行記

AWS Casual Talks #3 @ Cookpad

id:myfinder

経緯

星野さんに反応したら

星さんから連絡が来た

自己紹介

  • id:myfinder
  • まいんだー
  • エム・ティー・バーン株式会社
  • サーバサイド / Android

AWS 利用経験

awssumit

カジュアルユーザ

です :)

先にお知らせ

MySQL Casual Talks vol.7

  • 12/12(金)開催
  • 参加登録 -> いまから
  • トーク/LTネタがある方はお気軽に^^

今日話すこと

  • "どオンプレ環境"で作ったサービスを最近 AWS に移設しました
  • 移設するにあたって、運用環境を大きく変えました
  • AWS x Mackerel でとても捗っています

対象のサービス

http://mtburn.jp/

メディア企業の皆様

どしどしお申込み

ください

移行前の環境

オンプレ+S3/CloudFront(とか他のCDN)

移行前の環境

  • Single Segment
  • データセンター提供のマネージドDNS
  • 箱物ロードバランサ / 大手メーカー製サーバ / 一部自作機
  • CentOS 6.x / cobbler / puppet / RackTables
  • Hadoop 担当が構築 / 運用
  • MySQL/Redis 担当が構築 / 運用
  • Nagios / CloudForecast / GrowthForecast
  • 足元のディスクに吐いたログをでっかいサーバに収集して集計

よくあるオンプレ環境でした :p

抱えていた懸案

"調達"と"実装スピード"

急速に立ち上がっている状況

high-growth

オンプレ

すぐ調達できない

厳しい＞＜

移行で変えた点

  • 足元にログ吐くな
  • Single Segment -> Multi-AZ
  • マネージドDNS -> Route53
  • 箱物LB -> Elastic LoadBalancing
  • 物理サーバ -> EC2
  • CentOS -> Ubuntu
  • cobbler -> cloud-init
  • puppet -> ansible
  • MapReduce/Hive -> BigQuery
  • MySQL -> RDS(MySQL)
  • Redis -> ElastiCache(Redis)
  • 一部 Docker でコンテナデプロイ
  • Nagios+CloudForecast -> Mackerel

つまり

アプリ以外全部

アプリサーバ

  • 足元のストレージに吐いたログをscpとかで収集して集計していた
  • fluentd でログを各所に投げる形に
  • fluentd 自体のログも他に投げる

fluentd

Single Segment

過去の例はオンプレ事情の考慮が必要だった

aws_old http://aws.amazon.com/jp/solutions/case-studies/freakout/

Multi-AZ

今回構築したのはこんな感じ aws

Multi-AZ

  • 4セグメント
  • 後ろのセグメントはマネージドサービス用
  • RDSとかElastiCacheとか用

マネージドDNS -> Route53

  • 履歴機能とかはあったけど余りプログラマティックではなかった
  • ヤバい点は NS レコードを変更できない(！)こと
  • Roadworker を使えば git で管理できるので急いで引越

箱物LB -> Elastic LoadBalancing

  • ハードウェアロードバランサにはとても救われた
  • 一方でハードウェアロードバランサおじさん業が必要になる
  • 最初からキャパシティを見切れない環境では新規に買うのもためらわれる
  • SSL を箱で処理してたけど ELB も SSL 受け持ってくれるので特に問題なし

物理サーバ -> EC2

  • NAT インスタンス不使用
  • すべての EC2 インスタンスに Public IP を付与
  • アクセスコントロールは Security Group で設定
  • 個別のインスタンスに名前は付けない
  • したがって内部 DNS 廃止 / IP 付与も DHCP 任せ

命名が必要なものは

マネージドサービスを使う

or

EIP をつけて個別管理

CentOS -> Ubuntu

  • 事例の時は独自の AMI を作っていた
  • update への追随がダルくなるのでやめたかった
  • AWS でまともな CentOS を使おうと思うと Rightscale の AMI を魔改造する羽目になる
  • 標準提供で一般的なディストロの方がメンバーの理解が早い
  • 使ってた Travis CI も Ubuntu だし
  • 独自の yum リポジトリとか作っていたけどそういうのを捨てた
  • 思い切って捨ててみたら実はそれほど必要なかった

cobbler -> cloud-init

  • 素直にシェルスクリプトで書いておけば良い
  • ハードウェアの種類が多いと cobbler の snippet がカオス化したりする
  • ex. ethx で良かったはずの記述が DELL のサーバ買った瞬間 enx の対応を迫られる
  • ex. Hadoop のために 2U のサーバみたいなのを買うとどでかいパーティションをほげほげする対応に迫られる
  • そもそも後述の BigQuery に移行したからこれは関係なくなった :p

puppet -> Ansible

  • chef-soloも検討したけど複雑なことをやる必要がなくなった
  • yaml だけでいい Ansible の方がメンバーの学習が早いので採用
  • 徹底して各 role が受け持つ範囲を小さくしたので分岐が要らない
  • 複雑になり(そう|なる)のは、問題の切り分けができていない可能性大

Ansible最大の利点

Dynamic Inventory 機能で

Mackerel 連携が簡単

$ ansible -i mackerel.py all -m ping -u foobar

Hive/MapReduce -> BigQuery

  • ついに実用段階に入った BigQuery
  • fluent-plugin-bigquery 0.2.4 で timestamp 型サポートが入った schema
  • Redshift と比較検討したけど BigQuery のほうが要件に合ってた
  • 続きはLTで

MySQL -> RDS(MySQL)

  • 事例の頃はオペレーションが変わるのを避けたかった
  • オンプレ脳で作ったネットワーク&オンプレとの連携を考えなくてよくなったので活用
  • MySQL Casualもよろしくね!!

Redis -> ElastiCache(Redis)

  • 冗長化や自動バックアップ対応なので独自構築をやめた
  • auto failover サポートが発表されてさらに安心

Dockerを使いはじめる

  • ついに実用段階に入った Docker
  • 手始めに fluentd / Norikra をコンテナデプロイしてます
  • 本番で使ってる base image は Docker Hub に up してあります
  • Deploy は cap で docker pull -> docker stop -> docker run するだけ
$ cap deploy:container:td-agent
$ cap deploy:container:norikra
  • graceful restart が必要なものの利用にはまだ課題がある
  • 後述の private registry は build 忘れや push 忘れが発生しがちなので Docker Hub の有料プランに build とレジストリを押し付けたい
  • --link とか良い機能だけど人類には早い

レジストリ構成

S3 バックエンドでプライベートレジストリを構築 docker-workflow

S3 + Private Registry

RackTables + Nagios + CloudForecast -> Mackerel

  • サーバリストの管理/連携で消耗していた
  • role ベースでの管理に移行してサーバに命名することをやめた
  • 個別のサーバにログインするオペレーションは基本しない
  • サーバ情報管理の中心を Mackerel にした

Mackerel + Slack

mackerel_notify

携帯がアラートメールでうめつくされるみたいなのもなくなった

"デフォルトでSlack"

oranie

AWS x Mackerel

  • 実際運用しているやつから抜粋

グラフの連続性

当初8ノードで運用開始

8nodes

その後4ノードに変更

4nodes

roleベースでグラフは継続

8to4nodes

CloudWatch 連携

公式の手順でカジュアル

cloudwatch

Norikra

to

Mackerel

fluent-plugin-(norikra|mackerel)でイナフ

norikra

分速で売上/支払を見る

growth

ホスト登録 は

cloud-init で

mackerel-agent を

install すればイナフ

aws-icon.png x mackerel-icon

advance your ops

まとめ

  • "どオンプレ環境"で作ったサービスをAWSへ移設できました
  • 移設するにあたって、運用環境をやりたい放題に大きく変えました
  • AWS x Mackerel でとても捗っています
  • MTBurnはサーバサイド/スマートフォンのエンジニアを募集してます
  • MySQL Casual もよろしくお願いします

質疑など?

おわり