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
95
BuildKit を使った Scala アプリケーションのテストと高速化 @ Docker Meetup Kansai #2
i2tsuki
1
570
20180530LINEDeveloperMeetupRedis-redis-for-mackerelio
i2tsuki
0
470
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
今日からはじめるプラットフォームエンジニアリング
jacopen
3
200
Dynamic Reteaming And Self Organization
miholovesq
3
550
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
0
290
4/16/25 - SFJug - Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
2
120
SnowflakeとDatabricks両方でRAGを構築してみた
kameitomohiro
1
420
「経験の点」の位置を意識したキャリア形成 / Career development with an awareness of the “point of experience” position
pauli
4
100
意思決定を支える検索体験を目指してやってきたこと
hinatades
PRO
0
170
AIエージェント開発手法と業務導入のプラクティス
ykosaka
2
1.4k
Mastraに入門してみた ~AWS CDKを添えて~
tsukuboshi
0
270
3月のAWSアップデートを5分間でざっくりと!
kubomasataka
0
120
アセスメントで紐解く、10Xのデータマネジメントの軌跡
10xinc
1
440
サーバレス、コンテナ、データベース特化型機能をご紹介。CloudWatch をもっと使いこなそう!
o11yfes2023
0
180
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Embracing the Ebb and Flow
colly
85
4.6k
The Pragmatic Product Professional
lauravandoore
33
6.5k
For a Future-Friendly Web
brad_frost
176
9.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
680
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Visualization
eitanlees
146
16k
Side Projects
sachag
452
42k
A Modern Web Designer's Workflow
chriscoyier
693
190k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Code Review Best Practice
trishagee
67
18k
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