20160909 5年目に突入したaws運用振り返り
TRANSCRIPT
![Page 1: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/1.jpg)
5 年目に突入した AWS 運用振り返り株式会社ネットマーケティング 管理本部インフラチーム
久松 剛
![Page 2: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/2.jpg)
話者紹介• 管理本部インフラチーム シニアマネージャー 久松 剛
• Omiai のインフラ担当として入社• 全ての IT インフラの責任者
• 慶應義塾大学大学院政策メディア研究科博士• 在学時のテーマ
• インターネットを用いた高画質リアルタイム動画配信• オーバーレイネットワークを用いた次世代インターネットの基盤技術研究
• 事業仕分けを経て現職
好きな AWS Service :EC2
![Page 3: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/3.jpg)
• 広告事業• アフィリエイト広告の専業代理店• ダウンタイムに拘る
• メディア事業( Omiai )• Facebook を活用した恋愛マッチングサービス• やんちゃなトラフィックと MySQL Query
• Switch 事業• Facebook を活用したスカウト型転職アプリ• Apache Tomcat を初めて導入
とは
![Page 4: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/4.jpg)
と• 2012 年 6 月 18 日 久松入社、オンプレミスの環境を棚卸• 2012 年 8 月 AWS セットアップ開始• 2012 年 10 月 3 日 Omiai オンプレミスから AWS への移行• 2015 年 1 月 8 日 Switch. AWS を使ってサービスイン• 2015 年 11 月 11 日 ALLADiN オンプレミスから AWS への移行
![Page 5: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/5.jpg)
非 VPC(EC2-Classic) の苦悩• 2011 年 8 月 AWS VPC 正式サービス開
始• 2013 年 12 月 4 日移行、 VPC デフォル
トに
→ 古くからのアカウント• EC2-Classic と VPC の苦悩を抱えている
• 具体的な苦悩• EC2-classic では利用できないインスタ
ンスタイプの登場• VPC Classic Link に感謝しながら移行• 最近入社した AWS Support の人に伝わ
らない
→ 移行だけで勉強会行ける
![Page 6: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/6.jpg)
インスタンスタイプはよく考えよう当初の予定
• (当時の) EBS の信頼性に疑問• Auto Scaling 前提で設計• ディスクアクセススピード
• /media/ephemeral0 > EBS• WEB サーバは S3-backed Instance で
無慈悲な現実• いつの間にか EBS-backed Instance が主流に• 高い Auto Scaling 化のハードル(後述)• /media/ephemral0
• アクセススピードは良い• IO ベースのコストも心配しなくてよいが・・・
• I/O エラー 1 回をどう見るか
![Page 7: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/7.jpg)
Auto Scaling の是非• 高負荷時・ピーク時のみ立ち上げることによるコスト削減のクラウドの理想郷• まとめ
• 不慮の時に対応できる人員• 監視• 折れない心• インスタンスタイプが売り切れることは“ある”
→AutoScaling だけで勉強会行ける
![Page 8: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/8.jpg)
過去一番辛かった 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.”• ただ十数台のインスタンス再起動を見守るしかできない・・・
• 以降は同様の状況はなし
![Page 9: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/9.jpg)
最も辛かったインスタンス移行• その昔、 Tokyo に AZ は 3 つあった
• そしてそこには NFS on EC2 があった・・・• 当時の nfs が抱えるジレンマ
• Magnetic しかなかった頃の 1TB EBS• 拡張できない• IOPS遅い• lsyncd超遅い• SnapShotBackup超遅い
• 同一 AZ で SSD選べず• ( DD とか mv が不可)
→低負荷時( 2 時 -7 時)に並列で rsync• 増えるファイル変更• EBS ・ネットワークパフォーマンスにバラ
つき• 時間帯を変えて複数回テストして見積
![Page 10: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/10.jpg)
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
![Page 11: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/11.jpg)
AZ を跨ぐか跨がないか• MAZ
• 対故障性の面で優位• AWS のパッチ・メンテナンスは AZ単位
• SAZ• (MAZ の場合 ) ある時を境に大容量データのやり取り時に伝送遅延時間が大きくなる
• レプリケーションなどに影響• DB について高トラフィックが発生するケースでは SAZ もやむなし
• だがしかし• 同一 AZ内より AZ を跨いだ方が TTL が短いケースも確認
![Page 12: 20160909 5年目に突入したAWS運用振り返り](https://reader031.vdocuments.mx/reader031/viewer/2022021813/587820571a28aba12d8b6569/html5/thumbnails/12.jpg)
まとめ• 低負荷なサービス・単発的なイベント
• Managed Service で十分• 高負荷なサービス・プログラム起因の障害が多いサービス
• CloudWatch だと粗い→ cacti / Zabbix等を導入• 負荷となる原因が分からない場合、低レイヤに踏み込める Unmanaged Service の方がよいケースも
• 息の長いサービス• 絶えず情報収集をする必要性• インスタンスタイプは常に最新を追いかけた方が良い