2010年6月26日にオープンソースカンファレンス 2010 Hokkaidoが行われたので行ってきました。
カンファレンスの裏?テーマが『次の一歩』という事だったので、自分自身の次の一歩としてこのブログを公開し、簡単なレポートを書いてみたいと思います。
失敗しない仮想化環境の設計・構築法
最初に受けたのはこのセッション。
仮想化環境を構築するにあたっての要件定義〜運用管理までのポイントが説明されてました。
内容の幅が広いので箇条書きでまとめてみました。
- 仮想化技術に関して
- 仮想化は普及期に入ったのではないか。(キャズムに来たのでは)
- 仮想化技術のメリット・デメリット
- 物理サーバ、仮想サーバ(単体ラックサーバ上)、仮想サーバ(ブレードサーバ上)のメリットとデメリットを比較。
ある程度の規模を超えるならブレードサーバが良い。
ただしブレードコントローラの障害には注意が必要。 - 物理サーバなら障害点を極小化できる。
- 物理サーバ、仮想サーバ(単体ラックサーバ上)、仮想サーバ(ブレードサーバ上)のメリットとデメリットを比較。
- 要件定義
- 仮想化自体を目的にするのではなく、仮想化導入後の目標を明確にすべき。
- 成功とする数値基準を出そう。
- 仮想化は銀の弾丸ではない。何かを得れば何かを失う事もある(集約率と対障害性など)
- CPUの仮想化
- 仮想CPUの割り当て数だけ物理CPUをロックする。
- 仮想CPUの割り当てを減らすか物理CPUを増やす事でスループットを向上させる。
- ストレージ
- やっぱりストレージがボトルネックになる。今はストレージにお金をかけるべき。
- 必ずストレージは不足するので、次の一手を考えてストレージを選ぶべき。
- これまではiSCSIやFC接続の共有ディスクが定番だが、高速ディスクによるDASも増えるのではないか。
- SSDストライピングはめっちゃ早い。
- バックアップ・リカバリ
- 真面目に考えると大変。無理に仮想化対応させないでも良い。
- 導入前の事前検証
- 事前検証に関する基本的な考えとして仮想化に対する皮膚感覚を養う。
「仮想化するのが当たり前」の世界へのシフト。 - 有り合わせのものでもシステムは作れる。
- 事前検証に関する基本的な考えとして仮想化に対する皮膚感覚を養う。
- 運用管理
- 基本、物理サーバでの運用と同様になる。
- 死活監視だけではなく性能監視を追加すべき。
全体を通して、これから仮想化が当たり前になってくる流れのなかで如何にして仮想化に対する皮膚感覚を養うのかが重要だなと感じました。
PHP で大規模ブラウザゲームを開発してわかったこと
次に受けたのはこのセッション。あまりゲームをしない私も名前を知っているブラウザ三国志の開発記録的な内容でした。
ブラウザ三国志は札幌製だったんですね。
こちらはセッションで使用したスライドが公開されていますので、私がウダウダ言うより実際に見ていただいた方がいいと思います。
スライドはこちら → http://www.slideshare.net/ketaiorg/php-4638298
個人的には、
- O/Rマッパは使用せず実行するSQLを全て管理できる様にする
- ロック待ちを防ぐ為にテーブル分割をする
などDB周りのチューニングにかなり気を使ってる印象を受けました。
あと、EC2で実際にリソースバランシングを行っている事例を初めて聞きました。
PostgreSQL 9.0 アップデート:ホットスタンバイがやってきた!
午後イチで受けたのがこのセッション。PostgreSQL 9.0の新機能であるホットスタンバイレプリケーションについて、8.xまでのレプリケーションと比較しながら説明されてました。
自分はPostgreを全然使わないのでほとんど話について行けなかったです…すいません。
スライドはこちら → http://www.slideshare.net/ItagakiTakahiro/postgresql-90-update