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
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
7
810
信頼性に挑む中で拡張できる・得られる1人のスキルセットとは?
ken5scal
2
530
AIチャットボット開発への生成AI活用
ryomrt
0
170
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
220
The Rise of LLMOps
asei
7
1.4k
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.8k
DMARC 対応の話 - MIXI CTO オフィスアワー #04
bbqallstars
1
160
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
Taming you application's environments
salaboy
0
180
AWS Media Services 最新サービスアップデート 2024
eijikominami
0
200
Featured
See All Featured
How to Ace a Technical Interview
jacobian
276
23k
Into the Great Unknown - MozCon
thekraken
32
1.5k
How GitHub (no longer) Works
holman
310
140k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
28
2k
Automating Front-end Workflow
addyosmani
1366
200k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
Building Your Own Lightsaber
phodgson
103
6.1k
GitHub's CSS Performance
jonrohan
1030
460k
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