5 年目に突入した AWS 運用振り返り株式会社ネットマーケティング 管理本部インフラチーム

久松　剛

話者紹介• 管理本部インフラチーム シニアマネージャー 久松 剛

• Omiai のインフラ担当として入社• 全ての IT インフラの責任者

• 慶應義塾大学大学院政策メディア研究科博士• 在学時のテーマ

• インターネットを用いた高画質リアルタイム動画配信• オーバーレイネットワークを用いた次世代インターネットの基盤技術研究

• 事業仕分けを経て現職

好きな AWS Service ：EC2

• 広告事業• アフィリエイト広告の専業代理店• ダウンタイムに拘る

• メディア事業（ Omiai ）• Facebook を活用した恋愛マッチングサービス• やんちゃなトラフィックと MySQL Query

• Switch 事業• Facebook を活用したスカウト型転職アプリ• Apache Tomcat を初めて導入

　　　　　　　　　　　　　とは

　　　　　　　　と• 2012 年 6 月 18 日 久松入社、オンプレミスの環境を棚卸• 2012 年 8 月 AWS セットアップ開始• 2012 年 10 月 3 日 Omiai オンプレミスから AWS への移行• 2015 年 1 月 8 日 Switch. AWS を使ってサービスイン• 2015 年 11 月 11 日 ALLADiN オンプレミスから AWS への移行

非 VPC(EC2-Classic) の苦悩• 2011 年 8 月 AWS VPC 正式サービス開

始• 2013 年 12 月 4 日移行、 VPC デフォル

トに

→ 古くからのアカウント• EC2-Classic と VPC の苦悩を抱えている

• 具体的な苦悩• EC2-classic では利用できないインスタ

ンスタイプの登場• VPC Classic Link に感謝しながら移行• 最近入社した AWS Support の人に伝わ

らない

→ 移行だけで勉強会行ける

インスタンスタイプはよく考えよう当初の予定

• （当時の） EBS の信頼性に疑問• Auto Scaling 前提で設計• ディスクアクセススピード

• /media/ephemeral0 > EBS• WEB サーバは S3-backed Instance で

無慈悲な現実• いつの間にか EBS-backed Instance が主流に• 高い Auto Scaling 化のハードル（後述）• /media/ephemral0

• アクセススピードは良い• IO ベースのコストも心配しなくてよいが・・・

• I/O エラー 1 回をどう見るか

Auto Scaling の是非• 高負荷時・ピーク時のみ立ち上げることによるコスト削減のクラウドの理想郷• まとめ

• 不慮の時に対応できる人員• 監視• 折れない心• インスタンスタイプが売り切れることは“ある”

→AutoScaling だけで勉強会行ける

過去一番辛かった Maintenance Events

• 2014 年 9 月 28 日（日） 3:00-7:00 NEAR-TERM AWS Maintenance EVENT NOTICE• 9 月 25 日（木）に通知が届く• “You will not be able to stop/start or re-launch instances in order to avoid this

maintenance update.”• ただ十数台のインスタンス再起動を見守るしかできない・・・

• 以降は同様の状況はなし

最も辛かったインスタンス移行• その昔、 Tokyo に AZ は 3 つあった

• そしてそこには NFS on EC2 があった・・・• 当時の nfs が抱えるジレンマ

• Magnetic しかなかった頃の 1TB EBS• 拡張できない• IOPS遅い• lsyncd超遅い• SnapShotBackup超遅い

• 同一 AZ で SSD選べず• （ DD とか mv が不可）

→低負荷時（ 2 時 -7 時）に並列で rsync• 増えるファイル変更• EBS ・ネットワークパフォーマンスにバラ

つき• 時間帯を変えて複数回テストして見積

RDS か MySQL on EC2 か• NM での使用状況

• Omiai: MySQL on EC2• それ以外 : RDS

• RDS で十分なケース• 負荷が高くないサービス• 生い立ちが複雑でないプログラム

• MySQL on EC2 の利点• slow_query_log だけではお手上げ• DB側での pt-query-digest• cacti や Zabbix で細かくモニタリング

• http://www.slideshare.net/makaibito/mysql-on-ec2

AZ を跨ぐか跨がないか• MAZ

• 対故障性の面で優位• AWS のパッチ・メンテナンスは AZ単位

• SAZ• (MAZ の場合 ) ある時を境に大容量データのやり取り時に伝送遅延時間が大きくなる

• レプリケーションなどに影響• DB について高トラフィックが発生するケースでは SAZ もやむなし

• だがしかし• 同一 AZ内より AZ を跨いだ方が TTL が短いケースも確認

まとめ• 低負荷なサービス・単発的なイベント

• Managed Service で十分• 高負荷なサービス・プログラム起因の障害が多いサービス

• CloudWatch だと粗い→ cacti / Zabbix等を導入• 負荷となる原因が分からない場合、低レイヤに踏み込める Unmanaged Service の方がよいケースも

• 息の長いサービス• 絶えず情報収集をする必要性• インスタンスタイプは常に最新を追いかけた方が良い