とんがったデータベースエンジニアになれ！ db tech showcase 東京 2013レポート

PostgreSQLのサポート業務で分かった設計・運用のハマりどころ
富士通ソーシアルサイエンスラボラトリ（富士通SSL）杉山 貴洋氏

富士通SSLの杉山氏のセッションでは、自部署の業務としてPostgreSQLのサポート・サービスを日々行い、ユーザーより寄せられた質問から多い症例や同サポートチームの提示した回答を詳細に紹介。ここではそのいくつかを紹介する。

よくある質問と実用的な回答を紹介する富士通SSLの杉山氏（クリックで拡大）

「良くある冗長構成と、運用面での要検討次項を教えてほしい」。

通常はPostgreSQLのStreaming Replicationとpgpool-Ⅱを組み合わせた構成を提示している。検討事項では、何らかの理由でロングトランザクションの発生した場合にPostgreSQLのプロセスを削除したい事象が起こった時はpgpool-Ⅱによるフェイルオーバーを有効にしている場合には、PostgreSQLのプロセスは直接削除せず、pgpool-Ⅱプロセスにマッピングしてから削除を行う。

PostgreSQLのpostgresql.conf（設定ファイル）でパラメータについて設定方針が分からない。

回答質問の多くは主にメモリとログに関するパラメータついていることである。代表的なものにはshared_buffers、work_mem、log_line_prerix、log_min_duration_statementである。

運用後しばらくすると、反応の速度の遅いクエリが発生する。

性能劣化ではロングトランザクションが原因となって自動VACUUMが上手く機能せず、その結果不要領域が増加してしまい性能劣化を引き起こす。また、性能劣化で応答速度の遅いクエリがある場合には、プリペイドアド文を利用したクエリに最善でない実行計画が採用されていることが多い。

円滑なサポートを実現するアドバイスとしては「ユーザーが質問・問い合わせをする際には、ログの情報やコンソールに表示される情報はもとより、予測で構わないのでユーザー側で行ったことで原因となった作業を正直に話してほしい」と話していた。第一線で活躍する同氏ならではの説得力といえる。

位置情報を使ったサービス「スマポ」をPostgreSQLで作ってみた
スポットライト　浅羽 義之氏

スマポは2013年のグッドデザイン賞を受賞したO2Oサービスだ。買い物などでスマポが提携する店舗を訪れた際、専用アプリで「チェックイン」すると、自動的にポイントが追加され、たまったポイントで商品券など特典との交換ができる。

PostgreSQLを選択した理由は位置情報を扱える（PostGIS）ということが一番大きいが、他にもランニングコストを押さえたいことや、日本語マニュアルが充実していることが挙げられた。

上記の通り、スマポではPostGISを利用しており、店舗までの距離を近い順に出すためにPostGISの機能ST_Distanceを用い、あらかじめ登録されている店舗位置情報（緯度経度のデータ）からスマホからの現在位置情報を取得して計算している。

スマポの裏側を解説するスポットライトの浅羽氏（クリックで拡大）

運用DBはマスターとスレーブの構成で、アマゾンのロードバランサであるElastic Load Balancingで負荷分散を行っている。DB監視はNew Relicを利用し、良く話題にのぼるVACUUM/ANALYZEについては今のところ自動VACUUMに任せている。VACUUMをあまりさせたくないので様々なテーブルでフィルファクタを設定しているとのこと。

ANALYZEは1日1回特定ファイルを対象に行って統計情報を保つようにしている。レプリケーションの目的はあくまで冗長化と負荷分散なので、オペレーションミス等を補完する目的のバックアップとは混同しないでほしいと浅羽氏は話す。

スマポの場合Streaming Replicationを行っている。バックアップはAmazon S3を利用しているツールはWAL-Eを利用している。分析環境もPostgreSQLで行っているが、データを回収してパフォーマンスが要求されるので別データセンターに物理サーバーを置き、そちらで行っている。プロダクションのデータとマージしてKPIなどを出したいので、WAL-Eを使ってS3からトランザクションロールなどを持ってきてホットスタンバイモードで起動することで参照。本番データを見つつログのデータをマージして分析を行っている。

また、ウォームアップを必ず行っていることを紹介。キャッシュを暖めることで、再起動などの際いきなりサービスインした場合にもキャッシュが乗った状態で、パフォーマンスがかなり違うとのこと。

代表的にはPostgreSQLのshared_buffer、OSページのキャッシュ（free-mで確認できる）なのでキャッシュを乗せる方がよい。PostgreSQLのメジャーバージョンアップの際には、PostgreSQL9.1→9.2にアップグレードを行うが、PostGISも1.5から2.0にアップグレードしなければならない。このために、pg upgradeが使えない。ダウンタイムを減らしたいため、Slonyを利用した。

また、スマポがテレビで紹介された際の対応も紹介された。2週間前に対策会議を行い、リクエストは2,000増と見積もってオートスケールアップや一部をスレーブ側に投げるなど細かな対応も行ったが、実際には3,000リクエスト/秒以上となり、数分間停まるも何とか乗り切ったとのこと。さらに告知されていなかった再放送の際も2日前に気づき、結果的に普段の40倍以上のリクエストを捌くことができた。障害対応の参考にもなるセッションが印象的であった。

NonStop SQLはなぜグローバルに分散DBを構築できるか、データの整合性を保てるのか、その深層に迫る
日本ヒューレット・パッカード　原 敏光氏

NonStop SQLとはHPが提供するサービスでありHP NonStopサーバーという無停止型のサーバーによってもたらされる。38年の歴史を持ち、古くから北米のATMや証券取引で活用されてきた。NonStop OSという独自OSによって動作する。

HPがタンデムコンピューターとの合併によって、今日ではHPが利用してきたUNIX/Linux用の標準ハードウェア・プラットフォームに移植されて使いやすく、価格も押さえられている。絶対停まらない、データを失ってはいけないという思想は今も貫かれている。性能よりも可用性を重視しており、他のDBとは異なるこういった点が特徴という。

NonStep SQLについて熱心に説明するHPの原氏（クリックで拡大）

クラスターを組まずに1台でデータベースを動作させるので24時間365日停まることはない。証券取引所、クレジットカードで使われており、実に全世界のクレジットカードのトランザクションの1/3はNonstopサーバーで運用されている。今日では、低価格化によって、今流通業や製造業でも導入が増えているという。

基幹業務では高性能、拡張性が求められている。検索と更新のバランスが取れた高速性はアプライアンス型で実現されてはいるが、OLTPでは実際のトランザクションの性能がまだまだ求められている。データ整合性については益々要求が厳しくなっており、当たり前のことではあるが、高速性を追求すれば整合性が犠牲になるというジレンマが存在する。

拡張性については、昨今ではスケールアウト型のDBが流行っているが、殆どのものがBIやデータウェアハウスなどの参照系の領域に限定され、更新が多く派生する基幹系でも同様に拡張ができないかHPでは長年開発を続けている。複数のCPU間（クラスター構成であればサーバー間）で行われる2フェーズコミット処理が高速化のボトルネックとなる、しかし行わないとデータの整合性を保つことはできない。

トランザクション処理についても、NonStop SQLではオーバーヘッドを極限まで高速化している。トランザクション管理のソフトウェアモジュールについても出来るだけ並列実行性を上げている。これによりボトルネックにならない様な実装を長年行っている。通信のオーバーヘットを減らすことがポイントとなるが、HPではブレードのサーバー間はサーバーネットという独自のサーバー通信方法を採り、すべてのCPU間の通信はダイレクト・メモリーアクセスを行う。

また特徴的なのが、複数のCPUを一つのOSで動かし、論理的に4CPU、8CPU、16CPUといった具合にあたかも一つのサーバーの様な運用を可能とする点。ややこしい処理はOSレベルで処理してしまい、このことによってユーザーレベルではトランザクション処理が1/3程度の時間で済んでしまう。地理的に分散型DBを構築した場合にも通常のTCP/IPで繋がっていれば前述の様にシングル・システムとして分散型のDBを構築することができる。運用管理者は特別にノードを意識することなく運用することができる。途中で分散方法や分散領域を変更する場合においても、ノンストップでサポートしデータの整合性も補償する。

災害などで分散された一定地域ですべてのサーバーがアクセス不可になってしまった場合には、自立性を発揮し、アクセス可能な範囲で処理を続行するモードの準備がある。

可用性の課題の一つに、トランザクションで一定時間ロックが掛かり放しに陥った場合に自動にロールバックしてしまう（ヒューリスティック）ことがあり、これだとデータの整合性が失われてしまう。NonStopサーバー思想では運用で障害を補完することはなく、プロセスがホットスタンバイ型となっているので、障害が起こった時点から3秒程度でプロセスを復旧させ、処理を継続できる。

どの様な場合にもトランザクションを続行させる機能を持ち合わせるため、金融などの実績が多いことも頷ける。ハードウェアも含め1社が提供する垂直統合型でこその成立するサービスであるのかもしれない。

NoSQLを利用したサイト内エンジンサービスの開発・運用事例
神戸デジタル・ラボ　山本 浩生氏

神戸デジタル・ラボ山本氏のセッションでは、NoSQLを利用したサイト内エンジンサービスの開発・運用事例というテーマでKVSの運用ポイントが紹介された。

分散キーバリューストアは単純なデータの読み書きは早いがトランザクション処理や在庫処理のような複雑な処理には速度が遅くなるので向かないため、基本的には“適材適所”のスタンスで使ってもらいたい。どの様な場合にキーバリューストアを使うのかといえば、一番簡単で現実的なのはキャッシュとして利用することであり、これによってRDBの負荷を軽くすることができる。これはアプリケーションデータベースの負荷軽減にも繋がる。

また、限定的だがデータストア、ストレージとして使うこともできる。アプリケーションサーバーの参照の多いデータをキーバリューストアで実装されたデータストアで外に出すことで負荷分散に貢献し、吐き出されるログデータについても同様に負荷分散ができる。

KVSの運用ポイントを解説する神戸デジタル・ラボの山本氏（クリックで拡大）

検索エンジンで良くある症例としては商品検索が遅いケースがある。RDBにアクセスすればするほど遅延して行くが、この対策には検索対象をキーバリューストアで外に出してN-gram方式で整理することが必要だ。この対処でも件数が多いクエリの場合には遅くなることがあるが、キャッシュと組み合わせることで1秒間に70回の対応を目指して開発し、高負荷時でも長時間にわたって性能劣化が起こらない様に配慮されている。検索エンジンをKVSで行う場合はキャッシュの最適化などによって高速化が可能だが、検索の速度観点では平均値が改善されるものの最速値と最遅値での開きも大きいことがあるので、これからの改善ポイントでもある。

KVSには得手不得手があり、すべてをKVSで処理するというのは現実的ではない。KVSは小さいデータを扱うのに向いているが、1つ1つが小さいデータでも集合体としては大きなデータとなる様な場合は処理が遅くなってしまうので、必要な部分を常識的なサイズの少量データとして抜き出して使うのがポイントといえる。

熱く、現場で役立つカンファレンス

ここまで、いくつかのセッションを紹介してきた。どのセッションも非常に充実しており、会場は常に高い熱気を帯びていたため、もし機会があれば実際に参加して、Tongalistによる様々な話を体感してもらいたい。

熱心に説明を聞く参加者たち（クリックで拡大）

当日の一部のプレゼン資料はslideshareで公開されている。

【参照リンク】

db tech showcase 2013 Tokyo

（リンク先最終アクセス：2013.11）