はてなのインフラの歴史、そしてMackerelへ至る道とこれから
07:53:13
00:04
1
/
63
はてなのインフラの歴史、そしてMackerelへ至る道とこれから
Rakuten Technology Conference 2017
Oct 28th, 2017
Profile
id:
Songmu
(ソンムー)
Masayuki Matsuki / 松木雅幸
おそらくはそれさえも平凡な日々
http://www.songmu.jp/riji/
https://metacpan.org/author/SONGMU
はてな東京オフィス チーフエンジニア (2014年入社)
Mackerel プロダクトオーナー
50+ CPAN Modules
3 Times ISUCON Winner (今年も予選突破)
Mackerel
Mackerel
はてな謹製のサーバー管理・監視SaaS
小規模から大規模システムまで
ユーザー登録から3分でサーバー監視が可能
専属UI/UXデザイナーによる圧倒的な使い勝手
【宣伝】書籍発売中
【宣伝】みんなのGo言語
本日のお話
はてなのインフラの歴史を紐解きたい
今のMackerelにどのように思想が引き継がれてきたのか
過去を参照しつつ、未来がどうなるのか論じたい
株式会社はてな
2001年創業「老舗のWebベンチャー」
2016年上場
京都本社・東京本店
社員100人強/内エンジニア50人程度
CGMサービス展開
ノウハウを活かして、近年はB向けサービスや他社との協業的サービスも展開
時代区分
古代: 2001-2004
中世: 2004-2007
近世: 2007-2011
近代: 2011-2014
現代: 2014-
はてなシステムの考古学
より
時代区分
古代: 2001-2004
神話の時代
中世: 2004-2007
はてなグループ導入。歴史が綴られ始める
近世: 2007-2011
インフラチーム発足。社内仮想化基盤
近代: 2011-2014
AWS導入。ハイブリッドクラウド運用時代
現代: 2014-
Mackerelリリース。その他
はてなシステムの考古学
より
近世(2007-2011)
「はてなのインフラ いまむかし」
2008年8月
近世に至るまで
「はてなのインフラ いまむかし」
2001: 創業当初は1台のサーバーにすべてを詰め込む
2002: 徐々に3層構造(Proxy/App/DB)へ
2003: 自作サーバーを大量生産する時代
2008: さくらインターネットiDC移転
2008: Xenによる仮想化基盤
自作サーバー
2008年8月時点の規模と初代Mackerel
物理サーバー350台/仮想化して500ホスト
すでにサーバー管理ツールが存在(初代Mackerel)
当時のツール
仮想サーバーを立てるコマンド
Capistrano
Puppet
→ Infrastructure as Codeの走り
サーバーに丁寧に名前をつけていた時代
http://d.hatena.ne.jp/ideatester/20060211/1139687472
はてなのサーバー名は峠の名前にしていた
自転車好きの創業者の影響
「まっさらなサーバを30分で本番投入できるようにする」
http://blog.stanaka.org/entry/20070728/1185605498
当時外から見ていて衝撃を受けた思い出
「はてなでの仮想化技術の使い方」
https://www.slideshare.net/stanaka/how-to-use-virtualization-technology-in-hatena
2009年2月
物理500台/VM含めて890ホスト
「自作サーバーカンファレンス」
https://atnd.org/events/2052
@楽天(品川シーサイド)
https://www.slideshare.net/stanaka/original-server-conference
自作サーバー作っている会社がノウハウを持ち寄り
近代の萌芽(2011-2014)
はてなブログ
AWSとオンプレのハイブリッド運用へ
「はてなブログの下側」
https://www.slideshare.net/wtatsuru/jawsugkyoto2nd
2011年11月
当時のインフラの規模感
iDCは物理640台/VM含めて役2000ホスト
はてなブログの誕生
はてな初のAWS上で動くサービス
現サービスシステム開発本部長 id:onishi の肝煎りプロジェクト
独自の監視ツール
1.5代目 Mackerel
Chef導入
ハイブリッド運用へ
以降はてなは、オンプレのiDCとAWSのハイブリッド構成
新規サービスはAWS活用を増やす
社内サーバー監視ツールの作りなおし
2代目 Mackerel
はてなのNagios
https://www.slideshare.net/shoichimasuhara/3-ss-17097401
2013年3月 @ モニカジ #3
id:shouichimasuhara
Mackerel2(「当時の」新サーバー監視ツール)
RubyからPerlへ(おもしろポイント)
「はてなのサーバ管理ツールの話」
http://yapcasia.org/2013/talk/show/62304644-e25d-11e2-8767-0fa16aeab6a4
2013年9月 @ YAPC::Asia Tokyo 2013
id:y_uuki
Mackerelの思想の確立
サービス・ロール
メトリクス可視化
様々なツールと連携可能なサーバー管理のハブ的なツール
Nagios
Capistrano
Chef
IRC
Mackerel2のアーキテクチャ
Perl
agent構成
但しpull型監視
時系列データはRRDTool
そして現代へ(2014-)
SaaS版Mackerelの誕生
「2014年のウェブシステムアーキテクチャ」
http://blog.stanaka.org/entry/2013/12/01/092642
AWSの本格普及期
DockerとImmutable Infrastructure
2014年のモニタリング
「さようなら、自作サーバー」
http://blog.stanaka.org/entry/2014/03/07/201142
「ペットから畜牛へ」
https://www.slideshare.net/gmccance/cern-data-centre-evolution/17
サーバーに丁寧に名前をつけていた時代の終焉
「Immutable Infrastructure時代のサーバー管理」
https://speakerdeck.com/stanaka/immutable-infrastructureshi-dai-falsesabaguan-li-number-immutableinfra
サーバー使い捨ての時代
集合で管理する時代
SaaS Mackerel構想の発表
- 2014年3月
Mackerelベータリリースと正式リリース
https://speakerdeck.com/stanaka/mackerel-current-status-number-mackerelio
以降160+週連続機能リリース中
「エンジニアをワクワクさせるサーバー監視ツール」
監視はつまらないものではない
クラウド時代のベストプラクティスを提案
Infrastructure as Code
モニタリングの重要性の向上
すべてのサービスで健全性と一般的な監視関連のメトリックを同じように出力することをおすすめします。(中略) どれを選んでも、標準化するようにしてください。
Webサービスへの要求の向上
リアルタイム性
ビジネス成長のために統一的なモニタリングは必須
テストコードを書くのは当たり前になった。監視をしっかりやるのも当たり前
Infrastructure as Code分類におけるMackerelの守備範囲
Dynamic Infrastructure Platforms
AWS
Infrastructure Orchestration Tools
CloudFormation/Terraform
Configuration Registry
Server Configuration Tools
chef/puppet/Ansible
Infrastructure Services
Monitoring
/ Log / Deploy
サービス・ロール・ホスト
「Mackerelで採用している技術一覧とその紹介」
http://developer.hatenastaff.com/entry/mackerel-overview
社内版Mackerelとの違い
言語
Perl -> Scala/Go
TSDB
RRDTool -> Graphite
監視
Pull型 -> Push型
環境はオンプレ
DCリソースとの兼ね合い
ioDriveが使いたかった(と想像)
SaaS化で感じたメリット
コストセンターではない
最高のドックフーディング
SaaSは手触りが大事=UIがおざなりにならない
最近の動き
AWS移行とTSDB再設計
はてなシステム
「時系列データベースという概念をクラウドの技で再構築する」
https://speakerdeck.com/yuukit/the-rebuild-of-time-series-database-on-aws
スケーラビリティ確保のためにAWSマネージドサービス上に独自のTSDBを構築
強いハードで殴る富豪的なアプローチを辞め「サーバーレスアーキテクチャ」を採用
「はてなシステム構想」
https://speakerdeck.com/yuukit/the-concept-of-hatena-system
Repairable
Experimentable
"Droot" の紹介
サービスインフラの未来とMackerel
より細かい単位でより動的にインフラを扱う
問題を局所化するため
持続的なスケーラビリティの確保のため
リソースの最適化のため
より複雑にはなる
キーワード
コンテナ
再現性・独立性の高い環境としての利用
コンテナを利用して抽象度が高い概念が生まれてくる
サーバーレス
イベントドリブン
それらを踏まえた今後のMackerel
監視ツールとしてのMackerel
Infrastructure ServicesとしてのMackerel
より小さなサービスインフラの最小単位概念
コンテナ/ファンクション/サーバーレス
ネットワーク機器
IoT機器
イベント機能の拡充
開発や運用における様々な事象をトラッキング
アラート、Mackerelの操作、Deploy、ホスト増減など
イベント駆動で各種機能が連動
通知、アノテーション、アクション
メタデータの拡充
任意のKey−ValueをJSONデータとしてMackerelへストア
より動的で正確な Configuration Registry
メトリックデータをより詳細に
データ粒度向上
保持期間拡張
1分間隔のメトリックを400日保持
異常検知
機械学習
https://techblog.expedia.com/2016/07/28/applying-data-science-to-monitoring/
コンポーネント間の関係を表現
複雑な構成も分かりやすく管理可能
構成把握の容易化
影響範囲や原因の特定
以上
まとめ
はてなのインフラの歴史を紐解きながらMackerelにつながるまでお話しました
Mackerelは世の中のインフラの進化に合わせて進化しながら、サービス運用のベストプラクティスを示し続けます