Tech Sketch Bucket of Technical Chips by TIS Inc.

2014年度PGECons成果報告会参加レポート

Pocket

2015年5月14日、品川にてPostgreSQLエンタープライズ・コンソーシアム(略称:PGECons)の2014年度活動成果発表会が開催されました。本記事では成果報告会の様子をお伝えするとともに、PGEConsのワーキンググループのメンバーとして一年間活動した感想をお伝えしようと思います。

PostgreSQLエンタープライズ・コンソーシアム(略称:PGECons)とは

PGEConsとは、PostgreSQLをエンタープライズの業務システムに適用できるようにするため、PostgreSQL本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカル性の高いエンタープライズ領域へのPostgreSQLの普及を推進することを目的として設立された団体です。(HPから引用:https://www.pgecons.org/)

PGEConsにはワーキンググループ(WG)が1~3まであり、それぞれWG1は性能、WG2は異種DBからの移行、WG3は運用設計の分野でPostgreSQLの検証を行っています。

2014年度活動成果報告会

2014年度の活動成果報告会は5月14日に品川の株式会社日立ソリューションズ様の会場で開催され、160名もの方にお集まりいただきました。また今回初めて成果報告会に来たという方も多く、PostgreSQLへの関心の高さを感じることができました。

成果報告会

WG1~3からそれぞれ成果報告があり、それぞれのアジェンダは以下となっております。

■WG1(性能):大規模DBと仮想環境を見据えたPostgreSQLの性能検証

  1. スケールアップ検証(参照系)[定点観測]
  2. スケールアップ検証(更新系)/WAL改善
  3. 仮想化環境(KVM)検証
  4. コンテナ環境(Docker)検証

■WG2(移行):確実な移行を目指して- DB移行試験手法の調査 -

  1. スキーマ移行結果確認試験
  2. データ移行結果確認試験
  3. アプリケーション移行結果確認試験

■WG3(運用・設計):企業が求める堅牢なデータベースを実現するために~ディザスタ・リカバリとセキュリティ~

  1. 可用性
  2. セキュリティ

これらの成果全てを本レポートで紹介するのは難しいので、それぞれの検証の中でも2014年度初めて取り組んだ検証の一部や、TISが携わった検証についてご紹介したいと思います。また成果物自身はPGEConsのHPに掲載されており誰でも閲覧・入手することができますので、詳細を知りたい方はそちらも是非ご覧ください。

WG1(性能):大規模DBと仮想環境を見据えたPostgreSQLの性能検証

日本ヒューレット・パッカード株式会社の北山様からWG1の成果が報告されました。毎年WG1は大規模DBを見据えスケールアップ等の性能検証を行っておりますが、2014年度は稼働環境の多様化にも対応して新たに仮想環境上のPostgreSQLの性能についても検証を行ったそうです。
またPostgreSQLの9.4のリリースが予定では2014年9月だったところ、実際は2014年12月半ばと遅れてしまったため、WG1は9.4RC1を使用して検証を行ったそうです。

スケールアップ検証(更新系)/WAL改善

9.4 では更新系の性能が改善されたということで、2014年度は更新系のスケールアップ検証も実施されました。手法としては、データベースクラスタ以下(/data)とWALログ(/pg_xlog)を別々のボリュームに分け、コア数とクライアント数を変更してpgbenchでTPSを測定するというものです。結果は9.3と9.4RC1とどちらもコア数15の時に最大性能を示しました。また、9.3と9.4RC1とを比較してみると、コア数が少ない場合(15コア)は9.4RC1の方がより高い性能を示し、コア数が高い場合(60コア)はどちらも同等の性能を示しました。

WG1_3

コンテナ環境(Docker)検証

2014年度の新テーマとして、昨今流行りのコンテナ型仮想化ソフトウェアDockerを使用した検証も行われました。手法としては、Docker上にPostgreSQLを立てて、ネットワーク・ファイルシステムのそれぞれにDockerを使用・未使用した合計4パターンについて、参照系シナリオ・更新系シナリオを実行し性能を検証したそうです。結果は参照系シナリオの場合は4パターンのうちどのような構成であれ双方の環境に差はあまりなく、Dockerが参照性能に大きな影響を与えないことが確認できました。更新系シナリオの場合は、ファイルシステムがコンテナ内にある場合はそうでない場合に比べ性能が約半分まで落ちてしまうことが分かりました。

WG2(移行):確実な移行を目指して- DB移行試験手法の調査 -

株式会社富士通ソーシアルサイエンスラボラトリの杉山様からWG2の成果が報告されました。WG2は異種DB(主に商用製品)からの移行を調査しているWGです。2013年度はデータ移行や文字コードの移行、アプリケーション移行をメインに調査していましたが、2014年度は移行結果の確認をする「試験」をテーマに調査しました。また実際の移行検証にはinfoScoopというアプリケーションを使用したそうです。

データ移行結果確認試験

データ移行では、異種DBとPostgreSQLそれぞれに格納されているinfoScoopのデータ型が同一であるかどうかを確認するという手法で検証が行われました。検証の結果、タブや改行がエスケープされなかったり、片方で文字出力数の制限に引っかかってしまうということが分かり、データの移行にはデータの整形が必要になることが証明されました。
またMicrosoft SQL ServerとPostgreSQLのデータ整形の方針例も成果として報告され、移行を考えるエンジニアにとっては問題点と対応策が示された非常に貴重な報告であったと思います。

WG2_2

アプリケーション移行結果確認試験

アプリケーション移行では、移行元と移行先それぞれのDBで同一のSQLを実行し、返す結果が同一かどうかを確認するという方法で検証が行われました。
検証の結果、DBによってはNULLと空文字を区別しないものもあるためソート順序が異なるということが分かりました。

WG2は検証に複数ツールやシナリオを使用しておりそれらは成果物の方でも紹介されておりますので、移行を検討する方は是非そちらも参考にすると、成果物の情報と照らし合わせた検証ができるのではないでしょうか。

WG3(運用・設計):企業が求める堅牢なデータベースを実現するために~ディザスタ・リカバリとセキュリティ~

WG3は今年は可用性をテーマとしたディザスタリカバリ(略称:DR)と、2014年度からの新テーマであるセキュリティとの2つを検証し、可用性はTISの中西から、セキュリティは大日本印刷株式会社の亀山様から成果報告がありました。ちなみにですがTISはこのうち可用性のテーマに取り組みました。写真は可用性の成果報告をする中西です。

OLYMPUS DIGITAL CAMERA

可用性

可用性は災害対策を想定したDRについて調査しました。実際にDRを実現できるPostgreSQLの構成を9パターン洗い出し、それぞれを以下の様な観点で評価しました。

  • RTO(Recovery Time Objective):復旧時間目標…災害発生から何時間でサービスを復旧させることができるのか
  • RPO(Recovery Point Objective):復旧時点目標…サービス復旧時にどの時点までデータを戻すことができるのか
  • RLO(Recovery Level Objective):復旧レベル目標…どの程度まで機能や性能の低下を許容してサービスを復旧させるか

9つの構成は大きく分けて「データ保全を第一に考えたもの」と「サービス継続を第一に考えたもの」とに分けられますが、より高いRPOやRLOを目指すなら「サービス継続を第一に考えた」構成の方を選択したほうがよいことが分かりました。

運用技術検証~構築手順と復旧手順~

複数ある「サービス継続を第一に考えた」構成のうち以下の2つの構成について、実際の構築手順とメインサイト障害時の復旧手順とを調査しました。

  • masterがメインサイトのstandbyとDRサイトのstandbyそれぞれにSRする構成
  • masterがメインサイトのstandbyに、メインサイトのstandbyがDRサイトのstandbyにカスケードレプリケーションする構成

メインサイトの障害については「メインサイトのmasterに障害が発生した場合」と「メインサイトのstandbyに障害が発生した場合」の調査をしました。

調査の結果、DRを実現する構成は複数あれども障害発生個所により復旧パターンやコストは異なってくるため、一概にDRといえばこの構成を組むべき!というものではないことがよく分かりました。また実際に構築するときはその構成にあった復旧手順を事前に確立しておく必要があることも分かりました。構築や復旧の手順としてpostgresql.confやrecovery.confのパラメータの設定がありますが、この検証で採用したパラメータは成果物の方で紹介しております。

運用技術検証~遠隔地レプリケーションの実態~

上記の2つの構成について、実際にDRサイトを遠隔地に設置し負荷を掛けた状態でストリーミングレプリケーション(以下SR)させた場合、どの程度SRは継続するのかを調査しました。サイトの構築は昨今流行りのクラウド(今回はAWS)を使用し、メインサイトは東京リージョンに、DRサイトはシンガポールリージョンに構築しました。

調査の結果、メインサイトのmasterに膨大な負荷を掛け続けていくとDRサイトとのSRは遅延していき、遅延量が膨大になるとSRが止まってしまうことが確認できました。また、この遅延分をSRが止まってしまったstandbyに適用するといずれはそのstandbyは復旧することも確認できましたが、同時にRTOをより短くするにはどのような手法で遅延分を適用させるのかも重要なポイントであることが分かりました。

WG3_1

また検証時に測定したstandbyの未適用WAL量ですが、こちらは関数や統計情報をmaster/standbyそれぞれから取得し算出しなければ取得できないことが分かりました。実際に検証してみた者としての感想ですが、こちら当初はpg_stat_replicationビューからsent_locationとreplay_locationを取り出し算出すれば良いとしか想定してなかったため実際に算出するには大変苦労し、改めてSR運用の難しさを感じた点でありました。

セキュリティ

セキュリティはPCI DSS(Payment Card Industry Data Security Standards)というクレジット業界のセキュリティ基準をPostgreSQLがどこまで満たせるのかを検証しました。PostgreSQLがより多くの企業で使用されるようになってきている今、非常に実用的かつ貴重な検証結果であると感じました。

PCI DSS要件でDBが対応する必要のある項目は以下の9点で、これらに対しPostgreSQLが実際に対応できるのかどうかを調査するといったものでした。

アクセス制御として

  • アカウントポリシー機能
  • 不正アクセスチェック
  • 定期的なセッション情報の分析
  • 不正アクセスの動的遮断
  • アクセス時間外の接続検知
  • 長時間アイドル中の接続を自動的に遮断

暗号化として

  • 格納データの暗号化
  • ファイルシステムの透過的暗号化

ログ監査として

  • 出力したログの保全

セキュリティを担保するための様々な工夫がこれでもかというほど紹介されておりましたので、DBのセキュリティ対策を考えていらっしゃる方にとって成果物は大変貴重な資料となるのではと思います。

活動に参加してみての所感

TISがPGEConsの活動に参加するのは2014年度で3回目ですが私は初参加でしたので、一年間活動してみての所感も少し述べたいと思います。当初はそれぞれの企業から経験豊富な技術者が集った光景は大変壮観だと思いつつも、企業の背景・立場が違う人も多く果たして活動がスムーズにいくのか少し不安だったりしました。しかし背景や立場が違うもの同士で議論できたからこそ、通常の業務では得られない気づきが得られた場面も多々ありました。またそのような技術者達と一緒に検証できたことで個人での検証ではなかなか得られないような検証結果も得られ、結果としてPostgreSQLに携わる人に少しでも役立つだろう情報を提供できたことにすごく達成感を得ることができました。2015年度の活動はまだ本格的には始まっておりませんが早く検証してみたくてなりません!

2015年度の活動予定

2014年度も様々な検証結果が得られましたが、どのWGもまだやり残したことがあるようで残課題を2015年度に取り組みたいとのことでした。また、2014年度もそうであったように来年度もまた新しいテーマに取り組む可能性もあります。
TISも2015年度も活動に参加し、よりミッションクリティカルなPostgreSQLを目指して検証していきたいと思います。1年後に発表される2015年度の成果報告をお楽しみにお待ちください!

また、2013年度の成果報告会レポートもありますのでそちらの記事も是非ご覧ください!

エンジニア採用中!私たちと一緒に働いてみませんか?