Mackerel インフラ基盤 AWS 移行の舞台裏

Mackerel のインフラについて AWS への移行で何が変わったか、データセンタから基盤を移した技術、どのようにして安定した運用を支えているのかお話します。

Transcript

1. Mackerel インフラ基盤 AWS 移行の舞台裏 株式会社はてな Web オペレーションエンジニア 大野一樹(id: kizkoh) 2017-10-05 Mackerel Day #mackerelio 1 / 32
2. 自己紹介 大野 一樹 (@kizkoh / id:kizkoh ) 株式会社はてな Web オペレーションエンジニア Mackerel のインフラ、ミドルウェア基盤を担当 システムが動く仕組みを読み解くのが好き 2 / 32
3. 8/7, 8/21 Mackerel は AWS に移行しました
4. AWS 移行 Mackerel のサービス名を分けて移行 DB, アプリケーション, DNS と切り替えて移行完了 移行時の mackerel.io TTL は 60 4 / 32
5. なぜ Mackerel は AWS 移行したのか
6. Mackerel の AWS 移行のモチベーション 時系列データベース ハードウェア的スケールの限界、調達がたいへん データの堅牢性、冗長性の向上 データセンター運用コストの削減 ハードウェア、リソース管理の人的コスト 成長し続けるMackerelにおいてスケールの可能性を担保したい クラウドに移行して問題を解決したい 6 / 32
7. データと構成をそのまま AWS にデプロイ!! 7 / 32
8. ......すればいいだけで終わらない 8 / 32
9. 内部の構成は大きく手を入れました
10. 今日おはなしする内容 時系列データベースの移行 時系列データベースの運用 (Redis cluster) DNS の応答を短くする、DNSキャッシュサーバ アクティブスタンバイ構成の実現 AWS でのネットワークモニタリング
11. 時系列データベースの移行 11 / 32
12. 時系列データベースの移行 mackerel-agent, API が送るメトリックを保存 時系列データベースは自分たちで作り直した* *時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ 12 / 32
13. 時系列データベースの移行 移行時にはデータをコピーしながら二拠点 (AWS, データセンタ) に書き込んでいた 8/7 の移行でAWSで読み書きするようになった 13 / 32
14. 時系列データベースの運用 - Redis Cluster - 14 / 32
15. Redis Cluster 時系列データベースのコンポーネント 送られてきたメトリックデータを一番最初に 保存するところ 当初は Elasticache で運用する想定だった クラスタ作成後のノードが追加削除できない (将来的にできるようになってほしい)
16. Redis Cluster 複数の Redis をシャードとして分割している シャードの中で Active/Standby を構成 キーでシャードを分けている 16 / 32
17. Redis Cluster の運用 キーでシャードを分けている シャードが偏ることがある、つまり負荷が偏る シャードが偏るとどんなことが起きるのか CPU 使用率がボトルネックになっている maxmemory に当たって書き込めなくなる ➡ シャードを均等に保つ必要がある メトリックは redis プラグインで収集している クラスタ全体のイベントを監視したい 17 / 32
18. DNS キャッシュサーバ 18 / 32
19. DNS キャッシュサーバ 社内の権威サーバがデータセンタにある データセンタのサーバに問い合わせる構成 拠点ごとに権威サーバはない 社内ツールを使うために依存している 19 / 32
20. Unbound Unbound のメリット キャッシュを効率的にフラッシュできる 他のキャッシュサーバの選択肢 dnscache: フラッシュさせるには停止が必要 dnsmasq: すべてのレコードをフラッシュしてしまう unbound はメトリックを取得できる # unbound-control stats thread0.num.queries=1461682 thread0.num.cachehits=459062 thread0.num.cachemiss=1002620 ... time.up=5063213.127914 time.elapsed=5063213.127914 20 / 32
21. Unbound の運用 VPC 内のリゾルバは TTL 60 で固定されている 10.*.*.2, 169.254.169.253 Mackerel ホストの unbound は Google Public DNS に問い合わせる .io ドメイン不調時にはすぐに気付いた Mackerel も mackerel.io にメトリックを投稿してる Google Public DNS のネガティブキャッシュが Unbound にキャッシュされる Unbound のキャッシュが揮発するまで mackerel.io に接続できなくな っていた 21 / 32
22. アクティブスタンバイ構成の実現 22 / 32
23. アクティブスタンバイ構成の実現 DB はアクティブ,スタンバイ keepalived で mater,backup 構成 Virtual IP をルートテーブルに登録してルートをインスタンスに向ける ENI ベースの F/O と違って AZ 障害に対応できる 23 / 32
24. アクティブスタンバイ構成の実現 keepalived によるフェイルオーバ keepalived が master の異常を検知するとルートテーブルを書き換える ルートテーブルを書き換えるのは swiro 使っている* スプリットブレインが発生した場合も元に戻る構成になっている * taku-k/swiro: swiro - A switching route tool for AWS https://github.com/taku-k/swiro 24 / 32
25. AWS でのネットワークモニタリング 25 / 32
26. AWS でのネットワークモニタリング DC ではスイッチからメトリックを収集してた パケロスやチェックサムエラーなど AWS ではネットワークモニタリングが難しい よくわからないけどたまに不安定になってそうなことがある 影響範囲とか知りたい!! AZ 間の通信料をみたい 26 / 32
27. ネットワーク安定性モニタリング SNMP プラグイン* TCP パケットの再送、再送パケットの割合が見れる *https://github.com/mackerelio/mackerel-agent-plugins/blob/master/mackerel-plugin- snmp/README.md 27 / 32
28. AZ 間の通信料モニタリング iptables のチェインでみる VPC フローログでなくても見れる # iptables のチェインを設定 iptables -N az_send iptables -N az_recv iptables -A az_send -j ACCEPT iptables -A az_recv -j ACCEPT iptables -A OUTPUT -p tcp --destination 10.0.1.0/24 -j az_send iptables -A INPUT -p tcp --source 10.0.1.0/24 -j az_recv # カウントの初期化 iptables -Z # iptables -L -nv Chain az_send (1 references) pkts bytes target prot opt in out source destination 364 89124 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 28 / 32
29. まとめ 29 / 32
30. まとめ AWS 移行の見えない部分についてのお話 AWS 移行は様々な技術に支えられている Kinesis, DynamoDB, VPC Route Table, ELB Redis Cluster, Unbound, Keepalived, net lter AWS に移行したことで Mackerel 自体の監視、モニタ リングも進化している
31. 直近のリリース!! 31 / 32
32. Mackerelをよろしくおねがいします 32 / 32