SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

直近開催のイベントはこちら!

Data Tech 2022

2022年12月8日(木)10:00~15:50

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

DB Press

PostgreSQLを使い倒せ!NTTデータの挑戦


 12月5日に開催されたPostgreSQLカンファレンス2014にて、NTTデータは大規模な情報系システムにPostgreSQLを導入した経緯を紹介。厳しい要件をどのようにクリアしたのかを実直に語った。

 日本では海外と比較してPostgreSQLの普及率が高いと言われている。そこにはNTTデータの貢献も大きい。NTTデータは長らくPostgreSQLと関わってきているからだ。

 日本PostgreSQLユーザ会(JPUG)設立は1999年。JPUG活動にはNTTデータ関係者が何人も関わり、時には勉強会会場を提供することもあり、NTTデータはJPUGを深く、長く支えてきた。そうした水面下の貢献もあり、2006年には正式にNTTグループとして戦略的にオープンソースを活用している体制を整えるべくNTT OSSセンタを設立したという経緯もある。

 スタートが早いこともあり、NTTデータではPostgreSQLのノウハウが多く蓄積されており、人材も豊富に抱えている。今では同社ではOSSスタックは高い利用頻度となり、PostgreSQLのコモディティ化が進んでいる。

 トップランナーであればこそ、未知の困難にも直面する。講演ではNTTデータ 笠原辰仁氏、澤田雅彦氏(写真)から世界有数のエネルギー元売会社に導入した情報系システムが紹介された。販売情報をもとに集計もほぼリアルタイムで行うものだ。

澤田雅彦氏
澤田 雅彦氏

 データベースの規模は当初1インスタンスで10TB、論理テーブル数は900弱、SQLの数は2万以上。かなりの規模である。OSはRHEL 6.2、RDBMSはPostgreSQL 9.2、アプリケーションはTomcatを用いた。PostgreSQLで利用可能な拡張モジュールはほぼ全て採り入れたという。澤田氏は5つの要件をどのように克服したかを解説した。

課題1:無停止メンテを

 システムでは24時間データベースへのアクセスがあり、昼夜問わず大量バッチが行われているゆえ「止められない」。そのためシステムを止めずにメンテナンスを行わなくてはならない。PostgreSQLならメンテナンスのためのVACUUMやREINDEXがある。どうするか。

 「何はなくともまずVACUUM設計」と澤田氏。小規模テーブルは性能への影響が少ないため「auto vacuum」、大規模テーブルは慎重にメンテナンス枠にて手動で実施することにした。オンラインテーブル再編成用の外部モジュール「pg_reorg」、加えてインデックスのための自作ツールも組み合わせた。

課題2:災害対策サイトを

 重要なシステムならBCP(事業継続計画)は避けて通れない。東日本のメインサイトから西日本の災害対策サイトへデータをコピーすることとなった。

 検討段階ではアーカイブログの転送やハードウェアレベルでのレプリケーションも候補に上ったが、結果的にはストリーミングレプリケーションを採用。これは当然である。もともとストリーミングレプリケーションはNTTデータが独自に開発した機能をPostgreSQLの本体に寄贈したようなものだ。

 澤田氏はストリーミングレプリケーションを選択した決定打のひとつとして「頼れるサポート」の存在を挙げた。ストリーミングレプリケーションを開発したNTTデータ 藤井雅雄氏だ(参考「コアメンバーやコミッターに憧れて―ポスグレの若きエース、藤井雅雄さん」)。今ではPostgreSQLのコミッターである。

 とはいえ「本当に高負荷でも大丈夫か?」という懸念もあった。設計では最大負荷量から必要な帯域をサイジングしたものの、レプリケーションが追いつかなくなったらPostgreSQLが自動でアーカイブログからの復旧に切り替える。「今のところレプリケーションに起因する問題はありません」と澤田氏は胸を張る。

次のページ
課題3:大量SQLの性能確保

この記事は参考になりましたか?

  • Facebook
  • Twitter
  • Pocket
  • note
DB Press連載記事一覧

もっと読む

この記事の著者

加山 恵美(カヤマ エミ)

EnterpriseZine/Security Online キュレーターフリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Online の取材・記事も担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/6432 2014/12/22 12:40

Job Board

PR

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

2022年12月8日(木)10:00~15:50

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング