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.3k
AWS Startup.fm 企業の上場時に必要な監査要件とマネジメントサービスによる解決
i2tsuki
0
85
BuildKit を使った Scala アプリケーションのテストと高速化 @ Docker Meetup Kansai #2
i2tsuki
1
570
20180530LINEDeveloperMeetupRedis-redis-for-mackerelio
i2tsuki
0
460
Mackerel's monitoring and checks
i2tsuki
1
6.6k
Python Web Application Monitoring in Mackerel
i2tsuki
1
5.7k
Other Decks in Technology
See All in Technology
心が動くエンジニアリング ── 私が夢中になる理由
16bitidol
0
110
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
130
100 名超が参加した日経グループ横断の競技型 AWS 学習イベント「Nikkei Group AWS GameDay」の紹介/mediajaws202411
nikkei_engineer_recruiting
1
180
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
210
OCI Security サービス 概要
oracle4engineer
PRO
0
6.6k
SSMRunbook作成の勘所_20241120
koichiotomo
3
180
Mastering Quickfix
daisuzu
1
330
日経電子版のStoreKit2フルリニューアル
shimastripe
1
160
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
200
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
490
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
29
13k
Featured
See All Featured
Designing Experiences People Love
moore
138
23k
A Philosophy of Restraint
colly
203
16k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
The Cult of Friendly URLs
andyhume
78
6k
Ruby is Unlike a Banana
tanoku
97
11k
Typedesign – Prime Four
hannesfritz
40
2.4k
Six Lessons from altMBA
skipperchong
27
3.5k
GitHub's CSS Performance
jonrohan
1030
460k
Speed Design
sergeychernyshev
25
620
Rails Girls Zürich Keynote
gr2m
94
13k
YesSQL, Process and Tooling at Scale
rocio
169
14k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
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