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.2k
AWS Startup.fm 企業の上場時に必要な監査要件とマネジメントサービスによる解決
i2tsuki
0
79
BuildKit を使った Scala アプリケーションのテストと高速化 @ Docker Meetup Kansai #2
i2tsuki
1
560
20180530LINEDeveloperMeetupRedis-redis-for-mackerelio
i2tsuki
0
450
Mackerel's monitoring and checks
i2tsuki
1
6.5k
Python Web Application Monitoring in Mackerel
i2tsuki
1
5.6k
Other Decks in Technology
See All in Technology
Road to Single Activity
yurihondo
1
200
どこよりも遅めなWinActor Ver.7.5.0 新機能紹介
tamai_63
0
100
AIで変わるテスト自動化:最新ツールの多様なアプローチ/ 20240910 Takahiro Kaneyama
shift_evolve
0
200
より快適なエラーログ監視を目指して
leveragestech
4
1.3k
OCI で始める!! Red Hat OpenShift / Get Started OpenShift on OCI
oracle4engineer
PRO
1
130
Fediverse Discovery Providers overview
andypiper
0
150
事前準備が肝!AI活用のための業務改革
layerx
PRO
1
240
社内の学びの場・コミュニティ形成とエンジニア同士のリレーションシップ構築/devreljapan2024
nishiuma
3
240
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
13k
PDF Viewer作成の今までとこれから
hunachi
0
280
The XZ Backdoor Story
fr0gger
0
3.5k
なぜクラウドサービスで Web コンソールを提供するのか
shuta13
4
2k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Why You Should Never Use an ORM
jnunemaker
PRO
53
8.9k
Raft: Consensus for Rubyists
vanstee
135
6.5k
Designing for Performance
lara
604
68k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
600
Building Adaptive Systems
keathley
36
2.1k
Into the Great Unknown - MozCon
thekraken
29
1.4k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Speed Design
sergeychernyshev
22
420
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
36
2k
For a Future-Friendly Web
brad_frost
174
9.3k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.2k
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