« 8.Entropy Study on A and PTR Resource Records-Based DNS Query Traffic [セッション3: セキュリティ(1)] | メイン | 10. 持ち出し禁止データを外部から安全に利用する一方法 [セッション4: セキュリティ(2)] »

2008年12月 4日

9.はてなにおけるインターネットサービス群の継続的な開発と運用 [招待講演1]

カテゴリ：第1回　インターネットと運用技術シンポジウム(IOTS2008)

9.はてなにおけるインターネットサービス群の継続的な開発と運用
田中慎司（はてな）

・執行役員の人
・via NTT
・サーバインフラを支える技術

・はてなのはなし
・15のサービス
・はてなダイアリー、日記がキーワードでつながる
・はてなキーワード、キーワードでつながった日記を追いかけられる
・はてなブックマーク、ソーシャルブックマーク、集合値で人気・注目の話題が分かる、友人の見ているものが分かる、この前リニューアルした
・はてなスター、褒めることしかできないツール、相互に☆をつけあうとスターフレンドに

・コンセプト
・Fun & Creative
・ネットを通じて生活をゆたかにする
・ユーザーの集合知を極大化する

・会員80万人
・16億アクセス/month、6000万アクセス/day、1300万UU/month
・ハードウェア430台、仮想化により700台
・18ラック
・ピーク時300Mbps

・はてなでのサービス作り
・ユーザテスト・ヒアリング
・合宿
・社内発表・勉強会

・システムの全体像と解説
・三層構造、リバースプロキシ、アプリケーションサーバ、DB
・LVSを挟む
・三層構造がサービス毎に
・サーバ台数の割合、Web:DB=4:6～6:4
・全体の6～7割がweb or db
・非同期システムが増量中

・新ブックマークのシステム構成
・大変、、、40台から50台

・インターネットサービスの特徴
・スピードが大事
・永遠に完成はしない
・トラフィックの変動が急激
・小さい規模の頃は、ヤフーアタックとかですげーアクセスが急増、、、わかるわかる

・大規模サービスの運用
・スケーラビリティ、冗長性、省力運用、開発人数・開発方法、データ量

・スケーラビリティ

・多くのサービスはサーバ一台で動く、8GB/4コア
・が、大規模サービスはサーバ一台では動かない
・CPU負荷はスケールさせやすい
・I/O負荷はスケールが難しい
・用途毎のスケーラビリティ
・Webサーバはスケールさせやすい
・データソース（DB,Fileserver）は難しい、マスタのデータをどうスケールさせるか、パーティショニングなど
・パーティショニングをしすぎると、コストが高まる、検索などで困難なシーンも
・負荷の把握自社製、監視Nagiosを利用、OSの動作原理キャッシュメカニズムなどの監視

・スケーラビリティとソフトウエア開発
・大人数が利用することを前提に開発する必要
・少しのエンバグでサービスダウン、局所的な問題が全体に影響

・どのように解決？
・スケーラブルなアプリケーション設計・システム設計、OSSの積極利用
・推測しない、計測する
・プログラム言語の差異は全く支配的ではない
・ボトルネックは設計ミス、アルゴリズム選択ミス、I/O分散困難

・冗長性

・24時間365日100%の稼働率要求
・SPOF(Single Point of Failure)の除去
・Webサーバは冗長化しやすい
・データソースは冗長化が難しい
・基幹部分のネットワークは冗長化が難しい

・フェイルオーバー／フェイルバック

・冗長性とソフトウェア開発
・冗長構成で動作することを前提に開発する必要性

・解決策
・スケーラビリティとほぼ同様
・障害が発生したときの影響範囲の局所化
・故障することを前提に運用する、故障しやすい箇所の把握

・省力運用

・サーバが一台と複数台では運用コストが全く異なる
・350台のサーバ管理
・自作サーバ
・ケーブリングが大変になったり
・自作サーバ：金森、、、メーカー製の半額くらい
・ゴミが大量、、、

・運用が複雑になる箇所
・一台と450台で比較
・libcのセキュリティホール、アプリケーションのアップデート、サーバの設置場所、配線、、、

・多くの作業を自動化
・RPMやCapistrano
・OSインストールの自動化
・情報を整理する
・サーバ管理ツール
・IRC？

・データ量

・大規模サービスはデータ量が大きい
・データベースのレコード数、数百万から数億
・アクセスログ、1日で10GB
・大規模データ量に対する計算
・RDBMSの特性を正確に把握する
・アルゴリズムとデータ構造を工夫する、計算量を意識、分散アルゴリズム、統計処理 全体を対象としない
・分散処理系を活用する、分散ファイルシステム（HDFS, Mogile FS）、MapReduce

・サービス連携と継続的な開発のために

・柔軟なサービス開発、サービス間の疎結合
・高い効率・低コスト
・安定性

・サービス間の疎結合
・Pros、各サービス開発チームが個別に意志決定できる、開発速度の大幅な向上
・Cons、必要な情報が取得しにくくなる、開発コストの上昇、処理性能が劣化
・API化・利用の推進、生のデータベースを触らない
・プログラミング言語の統一
・作業の標準化

・API化・利用の推進
・API、Atom Publishing Protocol
・Feed、RSS?Atom
・汎用的なIFでアクセス
・ユーザへそのまま提供することも出来る

・プログラミング言語の標準化
・Python、Ruby、PHP、Perl、おなじレイヤーは一つに絞る、主にサーバサイドのウェブアプリケーション部分
・C/C++、メモリ効率、Apacheモジュールなど
・JavaScript、ActionScript、ユーザインタフェース

・プログラミングスタイルと設計
・オブジェクト指向
・他のエンジニアも触れるコードに

・保守性を考慮した設計
・アーキテクチャパターン、デザインパターン、イディオム

・MVC

・Model
・RDBを抽象化したライブラリ、ORマッパ
・ドメインロジックの再利用、DB詳細の抽象化
・Controller
・Webアプリケーションフレームワーク
・定型処理の抽象化
・View
・HTMLテンプレート
・デザイナとの絡み

・仕様を出来るだけコンパクトに保つ
・KISS、Keep It Simple, Stupid
・冗長な仕様は保守性を悪化させる

・アジャイル
・仕様書は書かない、スピード重視、コードをみれば分かる
・ミーティング重視
・テスト重要、テストが仕様である

・効率的な開発環境
・分散バージョン管理システム、git
・コードレビュー
・BTS、bug tracking system

・仮想化
・Xen
・仮想化によって得られるもの
・物理的なリソース制約からの解放、リソースの動的な変更、VMのマイグレーション・複製
・VM環境の統一か・標準化、自動設定ツール puppet、VMの自動的なインストールを可能に
・冗長化によるリソースの利用効率の低下を最小限に
・これはホントにうちも始めないと、、、

・んー、出来ることを出来る範囲で確実に進めているね

Q.Hadoopクラスターを新たに使い始めた差異の苦労した点
A.新たに使い始めた、全文検索のクローラーとして

Q.人数が増えてきて情報共有にかかるコストをどう抑えている？
A.アプリケーションの疎結合が基本、サービス開発チーム毎で決定出来る部分を増やす

Q.サーバ管理のIRCって？
A.監視システムのメッセージをメールと共にIRCにも流す、みんなでチェックしながら出来るので便利、情報共有ツールとして、コミットログなんかも流している、誰が何をやっているかとかもみんなで共有できる

Q.プログラミング言語の統一はどのように？
A.統一は、、、トップダウン、というかPerlが一番ノウハウがあるので

Q.JAVAはつかわない？　スクリプトって遅くない？
A.JAVAに強い人間がいない、、、スクリプトだからって遅い訳じゃない

Q.コードレビューでのセキュリティチェックで気にかけていることは？
A.diffをみてもらう、セキュリティはチェックリストがある訳じゃない、それぞれが判断

Q.性能orシンプル、VMを使ってサーバ台数が増えているけど、運用コストの増大は大丈夫？
A.そもそも、やらなきゃいけない冗長化を進めていたから増えている



投稿者 ymkx : 2008年12月 4日 16:29 |