id:myfinder
- 久森 達郎
- エム・ティー・バーン株式会社
- サーバサイド / Android
- "どオンプレ環境"で作ったサービスを最近 AWS に移設しました
- Mackerelを中心に運用環境を大きく変えました
- 結果、とても捗っています
オンプレ+S3/CloudFront(とか他のCDN)
- Single Segment
- データセンター提供のマネージドDNS
- 箱物ロードバランサ / 大手メーカー製サーバ / 一部自作機
- CentOS 6.x / cobbler / puppet / RackTables
- Hadoop 担当が構築 / 運用
- MySQL/Redis 担当が構築 / 運用
- Nagios / CloudForecast / GrowthForecast
- 足元のディスクに吐いたログをでっかいサーバに収集して集計
- オンプレはサーバの性能が箱で規定されるので、複雑なプロビジョニングを必要とする
- 新規リソースの調達リードタイムが大きい
- キャパシティを見切る事が難しい
- "そういうことに時間を取られると消耗する"
- クラウドへ移行すれば半分解決できる
- 残りの半分は？
- マネージドを積極的に活用する
- 運用方法自体も変える必要がある
- Mackerelをサーバ管理の中心にする
- Nagios/CF/GF/Puppet/RackTables -> Mackerel
- マネージドサービスの活用
- Route53/ELB/EC2 AutoScaling/RDS/ElastiCache
- BigQuery
- ツール/オペレーションの改善
- ログ収集方法の変更
- Puppet廃止、Packer + Shellへ移行
- デプロイ方法の変更
- サーバリストの細かいメンテが不要になる
- Roleベースでの管理/グラフの継続
- サービスメトリックが捗る
- 開発者が身近
携帯がアラートメールでうめつくされるみたいなのもなくなった
- 内部DNSもRoute53で扱えるようになったので移行
- 但しほとんどのサーバには名前をつけていないのであまり必要なくなった
- MySQLやRedisは自前運用しない
- フェイルオーバーやバックアップを勝手にやってくれたほうがいい
- MackerelとAutoScalingは先述のとおり相性良好
- Hiveと比較してコスト/速度/スケーラビリティすべてで勝っている
- もはや使わない理由がない
- 足元のストレージに吐いたログをscpとかで収集して集計していた
- fluentdでS3/BigQueryへ収集するよう変更
- fluentd自体のログもslackへ投げてトラブル検知
- EC2ではインスタンスタイプで必要なリソースを必要な機能単位で割り当てられる
- オンプレのように箱の性能に合わせたプロビジョニングが不要になる
- Packer + ShellScript で AMI を作ってしまえば十分
- S3を介したpull型deployへ
- 種サーバでビルドしたものをS3に同期
- 各サーバはS3から取得する
- 操作自体はCapistranoのMackerel連携で十分
- Auto Scalingで起動する際はcloud-initで取得処理を走らせる
- Auto Scalingで停止する際は通常のシャットダウン処理中で退役させる
- Mackerelを中心にサービス運用を考えた結果
- 結果としてInfrastructure as Codeを実践することになった
- 労働集約的な仕事から開放された
- 仕事の量を減らしつつ質をアップさせ、更に新しいことに取り組めるようになった
- 特定のクラウドにあわせて作りこむこともしないで済んだ
- オーバーエンジニアリングを要求されることもない
- Mackerelを中心に考える2015年代のサービス運用環境のいち事例を紹介しました
- オーバーエンジニアリングを避け、手入れもほとんどなく本来やるべきしごとに集中できています(^o^v
- エム・ティー・バーン株式会社では消耗しないで楽しく仕事をしたいサーバサイド/スマートフォンエンジニアのポジションがございます
- くわしくはお近くのエム・ティー・バーン社員までお気軽にどうぞ