0×0018 till I die

京都で行われたオープンソースカンファレンス2008 Kansaiに行ってきました。

はてなのCTO naoyaさんの発表を聞いて来たのですが、創業時から現在までのインフラ構築の工夫や苦労を語られていました。

はてなnaoyaさん
はてなを支えるバックエンドシステム
関西のエンジニア業界を盛り上げたい

アジェンダ
はてなのサービスを支えるバックエンドシステムを解説
創業時からこれまでの変遷

はてな
ハードウェア350台
14ラック
トラフィックはピーク時は200Mbps

はてなの2001年創業時
人力検索
PentiumsIIIの自作PCで動していた
CGIがボトルネック
CGI->Apache::Registryに変更

mod_perlサーバのメモリ消費が多い
mod_perlが必要ないリクエストもmod_perlが応答する
staticな情報もmod_perlが応答してしまう
Reverse Proxyで三層構造に
静的ファイルはmod_perlなしのフロントが
動的ページはバックエンドが返却

アクセス増加に伴いリソースが不足
Web/DBでハードを分けて分散
PostgreSQL->MySQLへ変更
Web+DB PressでMySQLがおすすめされちた
監視用にNagios導入−＞ケータイへメールして監視

Webサーバ自体のリソースの不足
Reverse Proxyとバックエンドのハードウェアを分離

当時のはてな
会社を支えるだけの収益はまだ見えず
受託開発を開始
同じようなプログラム開発の繰り返し
Hatenaフレームワーク作成
MVCフレームワーク
Perlオブジェクト指向
DB操作、mod_perl API

はてなアンテナ開発
複数の異なるサービスをひとつのサイトで運営
Reverse Proxyで振り分け

試行錯誤により徐々に三層構造に
フレームワークにより開発が効率化->はてなアンテナ
はてなアンテナのヒットによってサーバが増え始める

負荷が増大
mod_perlを増設
mod_reireのRewriteMapで振り分け
DBをテーブル単位で分割
巡回サーバを追加
結合していないテーブルを別のサーバに振り分けていた

増え続けるハードウェア
形がバラバラのPCケース
場所
熱
メンテナンス性

商用サーバは高品質だが効果的

サーバーケースを設計
ケースを設計
サーバーは自作
エアフローも考慮

MySQLが過負荷
MySQLレプリケーション
レプリケーションでレプリカを増やす
参照クエリはスレーブへ、更新はマスタへ
レプリケーションはサポートされたばかりで少し危なかった
振り分けロジックはフレームワークで吸収

mod_perlサーバを継続的に追加
MySQLスレーブを継続的に追加

ルータもLinuxボックス

サービスは週末に開発

2003年はてなダイアリーサービス開始
はてなダイアリーのバックエンド
過去の反省を活かしたテーブル編成

Revese Proxyが接続集荷場に

サービス毎に一つ以上配置
一部はDNSラウンドロビン
ロードバランサを買うお金がなかった
2004年2月東京移転
サービスを一日停止してトラックで搬送
当時のサーバー台数は50台
配送の様子をリアルタイム配信したりしていた

続々サービス追加
フレームワークのバージョンアップ
設計の見直し、UTF-8対応

サーバー追加
トラフィック追加

続くブログブーム
予測不可能なトラフィックの伸び
商用サーバ納期数週間では間に合わない

自作サーバの利点
早い、うまい、安い
柔軟に構成変更可能

mod_perlサーバが落ちると数分の一の確率で繋がらなくなる
Rverse Proxyはフェイルオーバー機能を持っていないため
mod_proxy_balancer追加

開発合宿でブックマークが開発

エンジニアが増加、サービス追加が続く

当時の運用の問題点
SPOF多数
まともにフェイルオーバーしていたのはmod_prxy_balancerのみ

人力対応の限界
回線飽和
ベストエフォート100Mbps回線
太い商用回線を借りるほどのお金がない
電力不足
サーバを追加したらブレーカーが落ちる
運用担当の踏ん張りに依存
消耗戦

運用の複雑化
属人的な運用体制の限界

Klabさんとの出会い
DSASオープンソースで完璧な可用性
こんなに簡単!Linuxでロードバランサ
ほとんどお金をかけずに耐障害性を上げていた

DSAS構築の経験からアドバイスを頂く
安心して寝たいから頑張る
データセンターを見学させていただく

LVS+keepalived
Linuxでロードバランサ
VRRPを使ってサーバの入れ替えを自答でやってくれるｍ
MySQLの手前にLVSを導入
内向けロードバランス
多数のSPOFが解消される

運用の効率化
アプリケーション担当とインフラ担当の仕事の分離が可能に
インフラ側はアプリケーションのことをあまり知らなくてもLVSの操作で切り替えができるようなった
さーくらインターネットiDCへ
DC分の収益は確保できるまでに成長
一年がかりでデータセンター移行
また車で移動・・・
データセンターで体を動かすとなぜか充実感

データセンター移行に伴い
インフラチームを発足、体制強化
古いサーバーをリプレース
CentOS、64bit化
Web+DB部分はほぼ冗長化

故障後のリカバリが面倒な箇所を一部商用サーバに
商用サーバはメモリの故障なども検知可能なのが助かった
メモリが壊れてビット反転、テーブルが壊れるなどあったので・・・

64bt化の追い風
メモリ4GBの壁を突破
メモリが安くなった
DBデータの大部分をOSがキャッシュできる
テーブル分割の必要性が下がる

MySQLのマスタがSPOF

マルチマスタ化
お互いにお互いのスレーブの関係

ファイルサーバがSPOF

DRBDの導入
ブロックデバイスのドライバ
ネットワーク経由でRAIDのようなことが出来る
DRBDで画像保持
lighttpdで画像は信
Squidでキャッシュ
大容量ファイルはMogileFS

新しいインフラが出来るまで
はてなインフラのターニングポイント
klabさんに感謝
チーム体制の役割分担
DC移転タイミングでの再設計
オープンソースでも高可用性インフラ

攻めのインフラ

フレームワークの刷新
Rails, Catalystと比べると古い
自社開発のPerlフレームワーク
Ridge+DBIx::MoCo
ORマッパDVIx::MoCoは近藤社長が開発
メソッドチェインが実装されている
ローカルで開発可能

自分たちで作る意味
コアの設計を自分たちで変えられる
サーバーリソースを使い切れない多数のホスト
バッチ処理専用サーバ
メルサーバ
トラフィックの少ないサーバ

仮想化技術の導入
Xen
1台のハードウェアで複数のOS
現在450ホスト中100ホストが仮想環境で動作中

仮想ホストをディスクレスサーバーで
中央のファイルサーバからOSのイメージを転送

ログ解析が終わらない
大規模データ処理に時間がかかる
Hadoopの導入
GoogleのMapReduceのOSS版
分散ファイルクラスタ

さらなる運用の効率化
OSの自動インストール
PXE Bootでインストール
はてな内RPMレポジトリ
Perlモジュール、カスタマイズしたソフト、自社ライブラリ

Puppet
Capistrano

数百台規模のサーバー情報の管理
スペック、用途、ラック番号、負荷グラフ
サーバー管理ツールの開発
サーバーホストの情報はサーバーから自動取得
負荷状況調査
他ツールとの連携
Nagios設定ファイルの自動生成Capistranoへデプロイ先を自動配信

バックアップツールNotch

はてなと風力発電

試行錯誤のうちに定番手法に行き着くことが多い

守りから責めに転じることができた
インフラの仕事はとてもクリエイティブ
自分たちの得意技を活かして運用効率化できる

インターン募集中

Tags: 未分類 //