Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Mackerel インフラ基盤 AWS 移行の舞台裏
Search
i2tsuki
October 05, 2017
Technology
6
10k
Mackerel インフラ基盤 AWS 移行の舞台裏
Mackerel のインフラについて AWS への移行で何が変わったか、データセンタから基盤を移した技術、どのようにして安定した運用を支えているのかお話します。
i2tsuki
October 05, 2017
Tweet
Share
More Decks by i2tsuki
See All by i2tsuki
ソーシャルゲームの長期運用 を目指すための SRE の取り組み - 10 周年を⽬指すコトダマンの場合 -
i2tsuki
5
2.5k
AWS Startup.fm 企業の上場時に必要な監査要件とマネジメントサービスによる解決
i2tsuki
0
92
BuildKit を使った Scala アプリケーションのテストと高速化 @ Docker Meetup Kansai #2
i2tsuki
1
570
20180530LINEDeveloperMeetupRedis-redis-for-mackerelio
i2tsuki
0
460
Mackerel's monitoring and checks
i2tsuki
1
6.9k
Python Web Application Monitoring in Mackerel
i2tsuki
1
5.9k
Other Decks in Technology
See All in Technology
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.5k
ペアーズにおけるData Catalog導入の取り組み
hisamouna
0
130
Riverpod & Riverpod Generatorを利用して状態管理部分の処理を書き換えてみる簡単な事例紹介
fumiyasac0921
0
110
AIエージェント完全に理解した
segavvy
4
270
ISUCONにPHPで挑み続けてできるようになっ(てき)たこと / phperkaigi2025
blue_goheimochi
0
140
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
110
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
abnoumaru
0
390
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
20k
17年のQA経験が導いたスクラムマスターへの道 / 17 Years in QA to Scrum Master
toma_sm
0
400
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
680
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
210
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
69
4.7k
Fireside Chat
paigeccino
37
3.3k
Typedesign – Prime Four
hannesfritz
41
2.6k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Designing for humans not robots
tammielis
250
25k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
A better future with KSS
kneath
238
17k
The Invisible Side of Design
smashingmag
299
50k
Speed Design
sergeychernyshev
28
860
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
Transcript
Mackerel インフラ基盤 AWS 移行の舞台裏 株式会社はてな Web オペレーションエンジニア 大野一樹(id: kizkoh) 2017-10-05
Mackerel Day #mackerelio 1 / 32
自己紹介 大野 一樹 (@kizkoh / id:kizkoh ) 株式会社はてな Web オペレーションエンジニア
Mackerel のインフラ、ミドルウェア基盤を担当 システムが動く仕組みを読み解くのが好き 2 / 32
8/7, 8/21 Mackerel は AWS に移行しました
AWS 移行 Mackerel のサービス名を分けて移行 DB, アプリケーション, DNS と切り替えて移行完了 移行時の mackerel.io
TTL は 60 4 / 32
なぜ Mackerel は AWS 移行したのか
Mackerel の AWS 移行のモチベーション 時系列データベース ハードウェア的スケールの限界、調達がたいへん データの堅牢性、冗長性の向上 データセンター運用コストの削減 ハードウェア、リソース管理の人的コスト 成長し続けるMackerelにおいてスケールの可能性を担保したい
クラウドに移行して問題を解決したい 6 / 32
データと構成をそのまま AWS にデプロイ!! 7 / 32
......すればいいだけで終わらない 8 / 32
内部の構成は大きく手を入れました
今日おはなしする内容 時系列データベースの移行 時系列データベースの運用 (Redis cluster) DNS の応答を短くする、DNSキャッシュサーバ アクティブスタンバイ構成の実現 AWS でのネットワークモニタリング
時系列データベースの移行 11 / 32
時系列データベースの移行 mackerel-agent, API が送るメトリックを保存 時系列データベースは自分たちで作り直した* *時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ 12 /
32
時系列データベースの移行 移行時にはデータをコピーしながら二拠点 (AWS, データセンタ) に書き込んでいた 8/7 の移行でAWSで読み書きするようになった 13 / 32
時系列データベースの運用 - Redis Cluster - 14 / 32
Redis Cluster 時系列データベースのコンポーネント 送られてきたメトリックデータを一番最初に 保存するところ 当初は Elasticache で運用する想定だった クラスタ作成後のノードが追加削除できない (将来的にできるようになってほしい)
Redis Cluster 複数の Redis をシャードとして分割している シャードの中で Active/Standby を構成 キーでシャードを分けている 16
/ 32
Redis Cluster の運用 キーでシャードを分けている シャードが偏ることがある、つまり負荷が偏る シャードが偏るとどんなことが起きるのか CPU 使用率がボトルネックになっている maxmemory に当たって書き込めなくなる
➡ シャードを均等に保つ必要がある メトリックは redis プラグインで収集している クラスタ全体のイベントを監視したい 17 / 32
DNS キャッシュサーバ 18 / 32
DNS キャッシュサーバ 社内の権威サーバがデータセンタにある データセンタのサーバに問い合わせる構成 拠点ごとに権威サーバはない 社内ツールを使うために依存している 19 / 32
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
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 / 32
アクティブスタンバイ構成の実現 DB はアクティブ,スタンバイ keepalived で mater,backup 構成 Virtual IP をルートテーブルに登録してルートをインスタンスに向ける
ENI ベースの F/O と違って AZ 障害に対応できる 23 / 32
アクティブスタンバイ構成の実現 keepalived によるフェイルオーバ keepalived が master の異常を検知するとルートテーブルを書き換える ルートテーブルを書き換えるのは swiro 使っている*
スプリットブレインが発生した場合も元に戻る構成になっている * taku-k/swiro: swiro - A switching route tool for AWS https://github.com/taku-k/swiro 24 / 32
AWS でのネットワークモニタリング 25 / 32
AWS でのネットワークモニタリング DC ではスイッチからメトリックを収集してた パケロスやチェックサムエラーなど AWS ではネットワークモニタリングが難しい よくわからないけどたまに不安定になってそうなことがある 影響範囲とか知りたい!! AZ
間の通信料をみたい 26 / 32
ネットワーク安定性モニタリング SNMP プラグイン* TCP パケットの再送、再送パケットの割合が見れる *https://github.com/mackerelio/mackerel-agent-plugins/blob/master/mackerel-plugin- snmp/README.md 27 / 32
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 / 32
まとめ AWS 移行の見えない部分についてのお話 AWS 移行は様々な技術に支えられている Kinesis, DynamoDB, VPC Route Table,
ELB Redis Cluster, Unbound, Keepalived, net lter AWS に移行したことで Mackerel 自体の監視、モニタ リングも進化している
直近のリリース!! 31 / 32
Mackerelをよろしくおねがいします 32 / 32