2008年2月29日

楽天株式会社におけるOSS活用の現状と今後の展開について [OSC2008Spring]

 [ReTweet This!] カテゴリ：OSC 2008 Tokyo/Spring

楽天株式会社におけるOSS活用の現状と今後の展開について
（サード・リアリティ時代に向けて）
楽天技術研究所 森正弥

・実は楽天はオープンソースを使っている会社
・今まであまりテクノロジーの側面を出してなかったけど、昨年くらいから出してみようかと、10周年だし
・テクノロジーカンパニーとして研究所を立ち上げてみたり、rubyを導入してみたり
・ruby開発者のまつもとさんは、楽天技術研究所のフェロー
・現在メンバーは11名
・楽天技術研究上の設立および、楽天の技術力を高める様々なテクノロジーの開発とかやってる

・松本さんも含めて、先週アメリカに行ってきた
・オレゴン州は実はオープンソースの聖地
・リーナスはオレゴン州に住んでる、他にも
・サンフランシスコから飛行機で2時間弱、住みやすい
・オレゴン州立大学がオープンソースに力を入れていて、オープンソースラボとか立ち上げてる
・州でベンチャーを支援するため、インキュベーション施設を作ったり
・オープンソース自体の研究もしている
・すごい

・日本だったらどうなんだろう？
・京都とか（はてな？）、札幌とか、松江（まつもとさん）
・東京に比べて田舎で、物価が安くて、住みやすい
・オープンソースはのどかな平和なところじゃないと育たない
・東京ってどうなの？
・私は思ったのは、日本でのオープンソース活用とか支援とかは、アメリカとは違う形で考えていかなきゃいけない

・楽天と言えば、ＥＡＧＬＥＳ、楽天市場（6万店、商品数2000万点、会員数は4000万、、、）
・従業員は毎月100人くらい増える、グループで5000人、開発部隊は600人、新卒が250名取ってるから平均年齢は4月に下がる、とか
・創業時のコンセプトは、日本を元気にしたい
・和歌山県北山村の村おこしに一役買う、まずい「じゃばら」を何とかする、花粉症に効く？　某テレビで流されて、あら大変
・インターネットを使って、日本の様々な地方にある多様性にリーチ出来るようにしたい
・アマゾンとは逆の発想、アマゾンは整然と、楽天はなんでもかんでも
・データベースはお店によって千差万別

・楽天のコア、楽天経済圏
・楽天市場が中心にあって、その周りにあるサービスを立ち上げている
・楽天スーパーDB、レコメンデーション、パーソナライズ、購買予測、KPIモニタリング
・慶応SFCにデータを提供、研究、分析を進めている
・わかったことは、ものすごくロングテール、ジャンルにかかわらず
・ネットの多様の活動は全てロングテール

・今後は台湾をとっかかりとして、世界展開を行う

----- こっからが本題

・OSSはどう活用すべき？　適材適所、Happy、サードリアリティ
・楽天はアウトソースを活用している？　手作り
・楽天はオープンソースを活用している？　活用している
・楽天の開発の実体
・最初は13店舗のみ
・最初は、SUN ＋ informix
・でもFreeBSDに替わった
・アキバで買ったパーツとか
・チャレンジすることが希望
・三木谷さんがソースを書いたことも

・2000年くらいに店舗は1500前後
・技術的には、二大潮流が確率、商用もオープンソースも積極的に
・でも、徐々にサーバやCPU増設でAPPサーバのライセンス料が高騰
・適材適所で使い分けるべき
・この頃、開発スタイルをオープンソース的に（共通ライブラリ管理チーム、CVSでのバージョン管理）
・LAMP推進部の設立

・そして、現在
・LAMPも商用も規模が拡大、サーバ数千台、開発体制は1200人規模（依託も含む）、OSSと商用をええ案配で融合
・データベース→Solaris、FreeBSD→現在はほとんど使っていない（一人の技術者に依存）、Linux→Web、メール、Debianがおおい、コストメリットが問題にならないくらい安定
・ネットワーク8Gbps
・トランザクションが多いから、通常はおきないような事例がおきる

・OSSと商用の違い
・信頼性、以前は信頼性が必要な箇所は商用、現在は区別せず
・パフォーマンス、スケーラビリティとライセンス料、商用化OSSの区別は無し
・高機能、アプリケーションの機能単位で分ければ問題ない
・保守、バグはどちらもある、商用DBMSが買収されたこととか、OSS毎でサポート企業と組んでくる
・結論、サービスをタイムリーに適切に作ることが大事、技術者のスキルとか希望とかそのレベルの話し、慣れたオープンソースを使ってもらった方がよい

・LAMP推進部が積極的展開
・PHP/MySQLは2002年ごろから本格導入、独自フレームワーク、ライブラリなどを適用
・Apache、Tomcat、Senna

・会社も、エンジニアも、お客様も、Happyにするために
・オープンソースの活用で、それが実現できればOK

・10周年を迎えて、チャレンジしていく、創業時を思い出し
・WebAPIを提供してみたり
・LAMP推進部から、アーキテクチャ標準化推進部へ
・Sennaが社内では熱い
・国際開発に向けた様々なOSSの取り組み
・Jungleプロジェクトの展開

・Ruby/Rails導入
・2006年8月にまつもとさんとブレスト
・まつもとさんがエンタープライズでの活用事例を作りたい
・ひそかにメンバーが結集
・勉強会、講演会、研修
・でもって、本格導入
・当初はバックエンドで活用していたけど、フロントにも導入してみた
・生産性→Great（1.6～3 x）、セキュリティ→（No Problem）、パフォーマンス→OK、運用性→Challenge、自分たちで開発、チャレンジ
・今は本格的に導入、myRakuten（igoogleみたいな）で本格的に
・
・情報爆発の時代に対応できるように
・大規模処理が出来るかどうかが企業の生命線に
・fairy & ROMA
・fairy、処理分散・CPU分散
・ROMA、データ分散・メモリ分散
・両方とも結構開発が進んできてる

・未来ビジョン、サードリアリティ→ググる
・現実とネットがどのような形で融合するかを考察
・Webの進化は、リア里程を進化させる
・より早く柔軟な技術活用

投稿者 ymkx : 2008年2月29日 18:12 |

pgpool-IIで実現するPostgreSQLの高可用性 [OSC2008Spring]

 [ReTweet This!] カテゴリ：OSC 2008 Tokyo/Spring

pgpool-IIで実現するPostgreSQLの高可用性
SRA OSS,Inc. 日本支社

・pgpool-II 開発背景
・ダウンタイムを限りなくゼロにしたい
・もっと早く！
・シングルサーバの限界、ハードウェアの故障による可用性の低下
・可用性と性能の両方を向上させるオープンソースミドルウェアを作りたい

・pgpool-IIの特徴
・ユーザと複数台のPostgreSQLの間に、pgpool-IIを設置することでユーザからは1台のデータベースに見える
・2004年pgpool初期版、2006年pgpool-II、2007年pgpool-II v2.0リリース、現在はpgpool Global Development Groupで開発＆メンテナンス
・BSDライセンス（商用利用可）でソースコードを公開

・pgpool-IIの主な機能
・可用性、同期レプリケーション（オンラインリカバリ）、Slony-Iとの連携、ログシッピング
・性能、参照クエリの負荷分散、パラレルクエリ、クエリキャッシュ、コネクションプール
・運用管理、Webベース管理ツール、独自の管理プロトコルの提供

・同期レプリケーション
・更新クエリを複数サーバに送信し同期を行う
・障害が発生した場合にはフェイルオーバーを行い運用を継続
・1行の更新性能は約1/2、バックエンドのPostgreSQLが何台でも

・オンラインリカバリ
・サービスを停止することなくノード復旧が可能、新規ノードの追加も可能、無停止でアップデートも可能
・洗練されたログベースによるリカバリ
・障害が発生してから、オンラインリカバリの設定が出来る
・管理ツールからボタン一つで操作

・同期レプリケーションの更新処理
・更新処理はマスターで行ロックを取る、マスター以外には並列にクエリを送信する（だから性能は1/2なのかな？）
・処理の結果（何件更新したか）によって、データ整合性チェックが行われる

・注意が必要なクエリ
・サブクエリを伴う更新クエリには注意！
・UPDATEの処理中に、他のユーザがINSERTされる可能性がある
・SQLの書き方に注意が必要
・たとえば、テーブルに対してON SHARE ROW EXCLUSIVE MODEでロックをかける
・同じテーブルに対して、UPDATEとINSERTが行われる場合、かつ新規に追加されるINSERT分がUPDATEの対象に含まれる場合
・INSERT INTO.. SELECT構文やVALUE句内のSELECT
・ユーザ定義関する内で、SELECTの実行結果を使って更新処理を行う処理

・この手の注意をしたくない場合、Slony-Iによる非同期レプリケーション
・更新クエリはマスタのみに送信、自動フェイルオーバー＋Slony-Iのマスタの切り替え
・テーブルの追加などスキーマの変更が出来ない
・非同期レプリケーションのため、フェイルオーバー時にデータロストする可能性がある

・ログシッピング
・PostgreSQLのPITRによるログシッピングを行う
・更新クエリはマスタのみに送信、そしてそこからログシッピング
・障害が発生した場合には、自動フェイルオーバー処理を実行
・フェイルオーバー後に、サーバを一台追加してバックアップサーバの構築も可能
・障害発生時にWAL領域のデータがロストする

・可用性のまとめ
・同期レプリケーション、デメリットはクエリ修正が必要かも
・Slony-Iとの連携、クエリの自由度は高い、デメリットは非同期レプリケーション、フェイルオーバー時のデータロスト、Slony-Iの操作がやや困難
・ログシッピング、クエリは何でもＯＫ、デメリットはフェイルオーバー時のデータロスト

・負荷分散
・同期レプリケーション、Slony-Iとの連携時に有効
・検索クエリは重みをつけて振り分け可能
・検索性能が向上

・パラレルクエリ
・データを分割して複数データベースで分担
・検索クエリを一斉に実行して結果をpgpool-IIでまとめる、問い合わせを並列に処理するので高速
・会計システムなどの意志決定システムなどに最適

・その他の機能
・コネクションプーリング（性能向上）
・クエリキャッシュ（性能向上）
・障害時に指定したコマンドを実行、管理者へのメール送信などが可能（運用管理）

・pgpool-HA
・HeartBeatと組み合わせてさらなる可用性向上を
・Active-Standby公正でpgpoolの死活監視
・仮想IPを利用することで、クライアントはサーバが切り替わったことを意識しない
・現状ではオンラインリカバリが出来ない

・pgpool 利用事例

・自動車産業のデータ交換システム（www.postgresql.org/communityfiles/14.pdf）
・クライアントは自動車メーカー
・データベースの負荷分散にpgpoolを利用

・Weblog解析システム（joeconway.com/terabytes_osc2005.pdf）
・520GBのデータを解析とか

・PostgreSQLでの同期レプリケーションでは、最もメジャー

・今後の予定
・オンラインリカバリも含めpgpool-II複数台構成のサポート

投稿者 ymkx : 2008年2月29日 18:10 |