tanamonの稀に良く書く日記

KEEP CALM AND DRINK BEER

OSC 2008 Kansai

event

7/18、19とOSC 2008 Kansaiに行ってきました。


その中でid:naoyaさんの「はてなのバックエンドシステムと開発手法、過去と今」という話がとても面白かったので、メモを残しておきます。


サービス開始当初は、言ってしまえばそこら辺の入門書レベルの知識なのですが、問題にぶつかる→問題を解消する、という流れの中で段々と高度なことに挑戦していく、という姿勢にとても感心しました。


続けることというのは、何よりも大事なことなんだなと思いました。

                                        • -

はてな紹介

  • 社員：35名
  • 会員数：80万人
  • UU数：1000万/月
  • アクセス数：200Mbps/秒
  • ハード：350台、14ラック

2001年当初


問題：CGIがボトルネック

  • Apache::Registryを入れる(一般的に200倍程度の速度アップ)


問題：mod_perlのメモリ消費量が高い

  • mod_perlを必要としないリクエストもmod_perlが応答していた
  • Reverse-Proxyを入れる。静的なものはフロントが、動的なものはバックエンドで処理
  • いわゆる三層構造


問題：アクセス増加に伴って、消費リソースの増加

  • WebとDBを分ける

2001年後半

  • DBをPostgreSQLからMySQLに変更
  • 高速で、Vacummレス、使いやすい、雑誌の影響？
  • 監視用にNagios(当時はNet Saint)を入れる
  • 携帯にメールが飛ぶようにした


問題：さらなるアクセス数の増加

  • Reverse-ProxyとWebを分ける


当時は収入源として受託開発もやっていた


問題：受託開発で同じ処理が多い

フレームワークを使い、人力検索を再作成

2002年5月


問題：複数のサービスが1台のサーバ上で動いていた

  • Webサーバをアプリ単位で分ける


問題：はてなアンテナがヒット

  • mod_perlを増設
  • mod_rewriteのRewriteMapを使う
  • JOINしないテーブル単位でDBを分ける


問題：パソコンをそのままサーバにしていた

  • 形がバラバラで場所を取る、熱で落ちる、メンテナンス性が悪い
  • しかし、商用サーバを買うほどお金が無い
  • ケースを自前で設計(製作所で作ってもらった)、サーバは自作のままで解決


問題：MySQLが過負荷で落ちる


問題：さらなるアクセス数の増加

  • mod_perlサーバを対か
  • MySQLスレーブの対か
  • (これまでの対策を応用できたので)スケールアップがやりやすかった

この当時のネットワーク機器


2003年3月

  • はてなダイアリーリリース、Blogブームでヒット
  • 過去の反省を生かし、テーブル設計を行う
  • 今も基本はそのまま


問題：Reverse-Proxyが接続数過剰

  • でもお金が無いので、真っ当な対策は行えない
  • 回線を増やしてReverse-Proxyを回線ごとに持つ(冗長性は無い)
  • サーバ移転で1日サービス停止
  • サーバの引越はトラックで運ぶ

サービスを矢継ぎ早にリリース

東京へ移転
フレームワークをVer.Up(UTF-8対応、設計見直し)


問題：トラフィック増加

  • サーバ追加、秋葉原でパーツを買う

自作サーバにしている理由

  • 商用サーバを買うお金が無いというのが元
  • 納期が早いという別のメリットも
  • 早い、うまい、安い、ということ
  • 柔軟な構成変更が行える


問題：mod_proxyがフェイルオーバしない

  • mod_perlサーバ(当時50台)が落ちると、ユーザは数分の1の確立で落ちる
  • mod_proxy_balancerを導入


サービス追加

  • RSS、マップ、グラフ、リング作成
  • トップページリニューアル
  • サーバが200台に


問題：SPOF(Single Point of Failure)が多数ある

  • 当時まともにフェイルオーバしていたのはmod_proxy_balancerのみ


問題：人力での障害対応の限界

  • 半年ぐらい運用で踏ん張っていた
  • 属人的な対応の限界


問題：お金無い

  • 回線飽和
  • 電力不足でブレーカが落ちる


光明見えず


KLabさんとの出会い


2006年9月
問題：SPOF解消

  • MySQLの手前にLVS(Linux Vertual Server)導入
  • 多数のSPOFが解消
  • 安定したフェイルオーバー／バックが実現
  • アプリ担当とインフラ担当の仕事の分離が可能になった


2007年1月
問題：電源問題の解消

  • さくらiDCへサーバ移設
  • インプレッサで運ぶ
  • 旧DC(社内)と新DCをVPNで繋ぐ
  • 現地で組み立て作業をやったり


問題：運用の組織化

  • インフラチームを発足、現在6名
  • 基幹ネットワーク設計の見直し
  • Web+DBはほぼ冗長化しLVS三層に
  • 精神的に落ち着けるようになった


問題：故障対応

  • 一部DBのマスタやLVSなどで、商用サーバを利用
  • 商用サーバは故障時にカーネルパニックを発生させてくれるので、故障の発見に気づける。
  • (ECC無しで)メモリが壊れているのに気づかないのが一番不幸


問題：メモリ4GBの壁

  • 64bit化でメモリ4GBの壁を突破
  • DBのデータの大部分をOSがキャッシュできる
  • I/O負荷を下げることができ、テーブル分割の必要性が下がる


問題：MySQLのマスタがSPOF

  • マルチマスタ化を行い、お互いスレーブにする
  • keepalivedで切り替えを行う
  • binlogが追いつかないという問題が残る


問題：ファイルサーバがSPOF

  • DRDBの導入(ネットワーク越しにRAIDするようなもの)
  • DRDBで画像を管理
  • lighttpdで配信
  • Squidでキャッシュ
  • MogileFSで(ここメモ取り損ね)


これらを1年がかりでやった
2008年1月完了

  • オープンソースでも高可用なインフラが作れる
  • LVS、keepalive、DRBD、Squid
  • チーム体制で役割分担が出来るようになった


ここから攻めのインフラ


問題：フレームワークのアーキテクチャが古い

  • フレームワーク刷新
  • 2007年に作り直し
  • Ridge+DBIx::MoCo
  • MoCoはid:jkondoが作ったO/Rマッパー
  • jQueryのメソッドチェーンのように利用できる
  • フレームワークを自作するメリットは、自分達の用途に合わせて使えるということ


問題：サーバリソースを使い切れていないホストがある

  • バッチ専用サーバ、メールサーバ
  • 必要だがトラフィックが少ない
  • Xenを導入
  • 1台のハードに複数のOS
  • 現在は450ホスト中100台が仮想化されている
  • Xenのディスクレスサーバをお試し中


問題：ログ解析が終わらない


問題：運用効率化

  • 運用ツール作成
  • PXE Bootでネットワーク越しにOSを自動インストール
  • 間違えてサーバ再起動で動いたりもした


問題：リソース管理


問題：サーバ情報の管理

  • スペック、王と、ラック番号の管理
  • ホスト情報はサーバから取得するツールを作成


他

  • Puppet
  • Capistrano
  • Notch(バックアップツール)


はてなと風力発電


最後に

  • Googleの初期インフラも自作だった
  • 何でも自分でやる、ということもいいのではないか
  • そうすることで、インフラが自社の強みになった
  • インフラも突き詰めることで、守りから攻めに転じられる
  • インフラもクリエイティブな仕事だと思う