はてなのインフラの歴史、そして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)

「はてなのインフラ いまむかし」

• https://www.slideshare.net/stanaka/hatena-infrastructer-from-the-beginning
• 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は世の中のインフラの進化に合わせて進化しながら、サービス運用のベストプラクティスを示し続けます