NTT OSS センタにおける PostgreSQLへの取り組み NTT OSS センタの活動紹介 NTTグループにおける事例紹介 2014. 9.18 NTT OSS センタ原野鉄也
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 1
NTT OSS センタ設 の 的 OSS 活 によるNTTグループ社内システムのTCO 削減を 的に 2006 年 4 設 事業現場における OSS 導 阻害要因の解消をめざす 情報収集を一元的にできないか プロダクトの保守サポート体制は大丈夫なのか 構築ノウハウ ( ミドルウェアの選定 構成方法等 ) を結集できないか エンタープライズ用途には OSS の機能強化 ( 高信頼化 高可用化 ) が必要ではないか など 2
ティルーお客様NTT OSS センタの位置づけ 下記の 4 つ (1 4) のミッションでグループ事業に貢献 NTT OSS センタのミッションと位置づけ プ社技術検証 検証済 OSS の導 推進 技術者育成 材交流 問合せ対応 導 援 プロダクト保守 プロダクト / ツール類の開発 NTT OSS センタ 1OSS 適 推進 (OSSVERT * 検証 ) 2ソフトウェア基盤技術 向上 3OSS トータルサポート 4 技術開発 (DBMS, 可 ミドル等 ) 連携 各種開発 OSS コミュニティグここを中心にお話します各サポート連携 サポートベンダ NTT 研究所等 *)OSSVERT :OSs Suites VERified Technically( 技術検証済み OSS 組合せ ) 3
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 4
OSSVERT モデル検証 Web3 層モデルを中 とした OSS ミドル組合せ検証により品質 性能確認 各種パラメータ値決定 適 領域明確化 失敗しない製品選定 戻りのない設計 開発 性能向上 迅速なトラブル解決 設定書検証データ 早い! 安い! うまい!? クライアント Webサーバ AP サーバ DBサーバ アクティブ スタンバイ Apache UltraMonkey JBoss/ Tomcat OpenJDK PostgreSQL/ MySQL Pacemaker/ Heartbeat 80 70 60 50 40 30 20 10 社内システムへの OSSVERT 導入数 73 74 69 62 52 44 38 14 OSSVERT モデル構成イメージ Amanda 0 2006 2007 2008 2009 2010 2011 2012 2013 5
OSS マイグレーション マイグレーション化に向けたノウハウ蓄積 援ツール整備 (OSSマイグレーション 援サービス ) マイグレーション工数削減ターゲット 工数 見積もり精度向上 見積もり稼働削減 事前検討 基本設計 詳細設計 製造 / 単体試験 ソースコード書換え稼働削減 結合試験 総合試験 商用 UNIX 上のアプリケーション 商用アプリケーションサーバ 商用データベース 商用 UNIX Java 言語 C 言語設計情報 SQL / DDL C 言語 / シェルスクリプト Linux 上のアプリケーション JBoss PostgreSQL Linux OS/ ハードへの依存が少なくツール不要 環境依存度が高く 移行見積もりや移行に時間がかかる領域はツールでカバー 6
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 7
コミュニティ活動 主要プロダクトの OSS コミュニティに積極的に参画 主なコミュニティ活動状況 プロダクト主なコミュニティ活動主要メンバ (OB 含む ) PostgreSQL Linux Heartbeat /Pacemaker PostgreSQL 開発 改善へ継続的にパッチ貢献 コミッタ PostgreSQLのレプリケーション機能開発への貢献で藤井が 本 OSS 奨 JPUG 理事励賞 受賞 (2010.10) 10) 企業ユーザ会 PGECons ち上げ (2012.4) Linux Kernel 開発 改善へ継続的にパッチ貢献 カーネルクラッシュダンプ機能開発等でフェルナンドが 本 OSS 貢献者賞 (2009.10) TOMOYO Linux 開発等で半 が 本 OSS 貢献者賞 (2013.2) 2) KVM 開発等で吉川が 本 OSS 奨励賞 (2013.2) 2) 受賞 NILFSメンテナ コミュニティのステアリングコミッティメンバとしてHeartbeatから Pacemakerへの移 に貢献 Heartbeat/Pacemaker 開発貢献で森が 本 OSS 貢献者賞 受賞 (2012.3) Pacemaker-PostgreSQL PostgreSQL 連携機能開発で松尾が 本 OSS 奨励賞 受賞 (2014.2) UltraMonkey コムウェア発 負荷分散ソフトウェアのコミュニティを牽引 コミッタ LKDTT (Linux Kernel Dump Test Tool) メンテナ TOMOYO Linux メンテナ NILFS メンテナ TOMCAT/ コミッタとしての活動が認められ 藤野が上級コミッタに昇格 (2012.7) 上級コミッタ TOMCAT 開発貢献で藤野が 本 OSS 貢献者賞 受賞 (2014.2) 2) コミッタ mod_jk JBossEAP 国 Red Hat 社との JBoss 品質改善 TF に参画し 品質改善に貢献 EAP6β 版評価プログラムに参画 品質改善に貢献 Linux-HA ステアリングコミッティメンバ / コミッタ Pacemaker メンテナ HornetQ コミッタ TUBAME コミッタ OpenJDK Java 障害解析 援ツール HeapStats を IcedTea コミュニティに公開 OpenJDKオーサ (2013.4) HeapStatsコミッタ HeapStats 8
コミュニティ活動 パッチ貢献件数 OpenJDK /HeapStats JBoss 23 1010 08 38 Tomcat /mod_jk 15 7 10 34 25 46 82 UltraMonkey 7 12 51 9 9 Heartbeat /Pacemaker 3 25 25 37 35 92 96 110 Linux 11 21 24 13 38 67 45 81 PostgreSQL 16 40 24 72 86 32 21 19 累積 310 0 50 100 150 200 250 300 350 400 450 2006 2007 2008 2009 2010 2011 2012 2013 9
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 10
OSS トータルサポートとは システムライフサイクルの各ステージで OSS 化をサポート システム化の検討段階での製品選定 性能検証から構築 援 運 時のトラブル対応まで OSS トータルサポートのスコープ ライフサイクルのステージ システム化検討 設計構築試験運用 情報提供 / 問合せ対応 提供サービスの例 検討支援 構築支援 検証支援 / 故障解析と回避策提示 11
問い合せ対応 (1/2) ポータルサイト経由の問合せ累計約 12,000 件 (2014 年 Q1) に対応 8 年間 +1Q 累計 12,284 件 年間 2,000 件程度 (2013 年度 ) 12
問い合せ対応 (1/2) 直近 4 年間で PostgreSQL の問合せ約 1,000 件 2013 年度問い合せで約 300 件あり 利 数は年々増加している 140 120 100 80 60 40 20 57 110 PostgreSQL 問合せ件数の推移 年間 308 件 (2013 年度 ) 185 239 310 350 401 459 495 553 625 684 779 直近 4 年間 992 件 1100 992 930 900 871 700 500 300 100 0 100 13
問い合せ対応 (2/2) 2013 年度における PostgreSQL の問合せ約 300 件 設定や機能に関する問合せが多い ( 約 6 割 ) 不具合解析 26% そのうち 仕様通り が約 4 割 PostgreSQLのバグ起因 1% 新規バグ 0% 品質 に問題なく 安定した運 が えている ノウハウ整備とその展開が重要 問合せ全体 傾向分析 ( 件 ) PostgreSQL 傾向分析 ( 件 ) 2013 年度 OS/ ミドルのバグ内訳 機能 24% 設定 25% サポート方針 3% その他 3% バージョンアップ 8% サポート方針 3% バージョンその他新規 1% アップ 12% アプリバグ 2% 17% アプリバグ 0% 設定ミス 6% 設定ミス 4% 機能 30% 仕様通り 9% 仕様通り 12% 不具合解析不具合解析 26% 33% 既知原因不明 8% 83% 原因不明 5% 設定や機能に関する問合せ約 6 割 その他 5% OS/ ミドルバグ設定 3% 32% 新規は 0 その他 4% 全体の約 50% DBMS バグ 1% 14
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 15
PostgreSQL への取り組み Background NTT 研究所において OSSデータベースの研究開発に着 した 2004 年当時 機能と開発体制から選定 オープンソース DBMS の比較 (2004 年当時 ) 機能 PostgreSQL(7.4) SQL の対応範囲 SQL92をほぼカバー 本語 字の対応 JIS, EUC 等主要コードを利 可能 MySQL(4.0) 副照会とカーソルの 部に制約があった種々の制約があった 開発体制 開発主体 ベンダ独 のコミュニティが開発 特定ベンダのプロダクトであり ダ しており パッチの受け れ等に パッチの受け れ等はベンダの ついて中 性が い 意向に左右される 海外コミュニティ開発コミュニティを含め活発 国内コミュニティユーザコミュニティが活発 ユーザコミュニティのみ活発 ユーザコミュニティが ち上がりつつあった 16
PostgreSQL の進化と OSS センタの関わり 中 期的な取り組みとして PostgreSQL 開発にも参画 開発 針議論への参画 ユーザ会 JPUG ポータルサイト運営 援 9.x において国内トップのパッチ貢献 黎明期 中規模構成をターゲットにした商 DBMSと同等の機能 性能の具備 2005 NTT 参画 2006 8.3(2008/2) 2007 OSS センタ設 8.1 2008 82 8.2 2009 8.4(2009/7) 9.1(2011/9) 2010 9.2(2012/9) 2011 2012 9.0(2010/9) 9.3(2013/9) 2013 発展期 規模構成 および適 領域拡 に向けた 機能性向上 商 DBMSからの移 性向上 2014 今後 MC (*) システム適 *)MC: ミッションクリティカル 17
PostgreSQL の進化と OSS センタの関わり エンタープライズ 途観点で新機能や性能改善の開発に貢献 NTT グループでは 83 8.3 からシステムへの導 が きく加速 最近はレプリケーション機能と HA を組合わせた PG-REX 構成も 字は NTT 貢献機能 8.3(2008/2) HOT: 更新性能向上 VACUUM 自動化 2005 2006 2007 91 9.0(2010/9) 9.1(2011/9) 同期レプリケーション パーティショニング強化 外部データラッパー 非同期レプリケーション 列 / 条件付きトリガ 2010 2008 8.4(2009/7) 2009 VACUUM 用メモリ自動管理 2011 2012 9.2(2012/9) インデックスオンリスキャン 大幅な性能向上 プラニング改善 レプリケーション進化 外部データラッパー改良 94(2014/9?) 9.4(2014/9?) 2013 9.3(2013/9) 2014 書き込み可能外部テーブル 更新可能ビュー / 実体化ビュー 高速フェールオーバ 外部データラッパー改良 18
PostgreSQL 開発 NTT が機能開発に取り組んだ機能のご紹介 開発に取り組んだ背景や課題 開発した機能の概要 1. レプリケーション (PG-REX) 2. 外部データラッパー 3. 移植の効率化 19
PostgreSQL 開発 - レプリケーション NTT が取り組んだ背景 課題 OSS センタ設 の頃より TCOの徹底的な削減 厳しい競争によりシステム投資は抑制傾向 HWも安価なものを組合わせてシステム要件を実現したい 特に 規模システムで要望が強い その上 定の信頼性も求められる 可 性の向上 サービス継続性に対する要求レベルの上昇 ダウンタイム時間の短縮化 99.99%(52.6 分 ) 99.999%(5.26 分 ) 共有ディスク 式の冗 構成では実現出来ないケースが スが 性能のスケールアウト DBサーバの処理性能向上では スケールアップが 般的 スケールアップは HWやSWの初期コストも きくなりがちまたサーバ分割 ( スケールアウト ) は設計 直しなどの開発コスト増に 20
PostgreSQL 開発 - レプリケーション PG-REX(http://sourceforge.jp/projects/pg-rex/) 最新版は PG-REX9.3 PostgreSQL と Pacemaker を組み合わせた 可 ソリューション 共有ディスク不要 : 低コストでHAクラスタを実現 待機系の有効利 : 待機系でも参照 SQL を処理可能 ユーザ ( 業務 AP) からの IF は同じ NOTPM 3500 3000 DBT-2 を用いた更新性能の検証 3157 3124 2785 切り替え時間は 10 秒 ~60 秒程度 2500 2000 仮想 IP 自動フェールオーバ機能 監視 制御 仮想 IP 1500 1000 500 プライマリスタンバイ 0 データベース同期レプリケーションデータベース 現用系待機系 PG9.1 REX9.1( 非同期 ) REX9.1( 同期 ) 検証環境条件 H/W CPU Xeon 2.66GHz 4core, MEM 18GB Strage 146GB 4 本 (RAID 1+0) S/W RHEL5.5, PosgreSQL9.1 21
PostgreSQL 開発 - 外部データラッパー NTT が取り組んだ背景 課題 外部データとの連係 販売履歴 応対履歴 課 履歴といった 量のログ情報を取り扱う RDBMSへのロード時間を短縮できないか 他システムとの DBMS 連携を う より柔軟 より簡単に他のDBMSと連携できないか 業務システム A OLAP システム 業務 DB-1 業務 DB-2 ログログログデータログロード (CSV) ログ (CSV) (CSV) 処理 業務 DB-A OLAP ( オンライン分析 ) データ分析者 業務 DB-3 ロード時間の長大化 DB 連携 他 DBMS との連携がしにくい 業務システム B 業務 DB-BB 業務オペレータオンライン業務 22
PostgreSQL 開発 - 外部データラッパー FDW( Foreign data wrappers ) 93 9.3 から contrib モジュールとして追加 外部データへアクセスする仕組み ( テキストファイル DBMSなど ) SQL 中で通常のテーブルと同じように記述できる 業務システム A OLAP システム 業務 DB-1 業務 DB-2 ログ (CSV) ログ (CSV) 業務システム B 直接アクセス fi le_fdw ロード時間の解消 業務 DB-A (PostgreSQL) 業務 DB-3 (PostgreSQL) 業務 DB-4 ( 商用 RDBMS) DB 連携 通常の SQL でアクセス pos stgres _f fdw _f fdw AP 業務 DB-B (PostgreSQL) 23
PostgreSQL 開発 - 移植の効率化 NTT が取り組んだ背景 課題 移植コストの低減 システム開発の多くは更改案件(OSSセンタへの相談の8 割以上 ) 商 DBMS から PostgreSQL への移 既存 APの流 率を めることが重要なポイント PostgreSQL 不採 理由 (*) 商用 DBMS 固有機能の移植コスト 短期間 & 高精度での見積りができない お客様事情 移 検討時にチェックするポイント 適 性 OSSがシステム要件への充 確認 機能 性能 システム間連携 運 期間 サポートレベル etc 他製品連携制約 性能不 移 が困難 *OSS センタ調べ 移植性 既存 APの修正量や修正難易度を確認 既存 APの記述 語や流 規模 互換 SQL の修正箇所 難易度 修正 法修正 法 商 DBMSの独 実装機能 例 ) パーティショニング PL/SQL シノニム など 24
PostgreSQL 開発 - 移植の効率化 orafce(https://github.com/orafce) Oracle に含まれる関数や機能を PostgreSQL で実 可能にするツール PGECons WG2 の成果物に参考となるドキュメントが 組み込み関数移 調査編 (https://www.pgecons.org/downloads/62) PostgreSQL+orafce がサポートしているパッケージの関数カバー率 (*) 実案件 (Java アプリ ) での PostgreSQL+orafce の関数カバー率 (*) 未対応 66% PostgreSQL 標準 +orafce 34% 未対応 27% PostgreSQL 標準 +orafce 73% db_syntax_diff *OSS センタ調べ (https://github.com/db-syntax-diff) APをPostgreSQLへ移植する際の影響箇所を検出するツール 影響箇所抽出作業の短縮化 10 12 10 8 6 4 *OSS センタ調べ 影響箇所調査稼働 ( ) ツール未使用 2 抽出の網羅性向上 品質の均 化 2 0 人日 エキスパートが実施 スキル依存なし ツール使用人日 25
PostgreSQL 開発 - その他周辺ツール その他 NTT が開発に関わった OSS( 部 ) pg_ statsinfo / pg_ stats _ reporter 統計情報を定期的に収集 蓄積し 稼働状況をレポートに出 http://pgstatsinfo.projects.pgfoundry.org/pg_statsinfo-ja.html pg_bulkload 速データロードユーティリティ http://pgbulkload.projects.postgresql.org pg_reorg オンラインで PostgreSQL のテーブルを再編成するツール http://reorg.projects.pgfoundry.org t pg_rman バックアップやリストアを簡単に実 できるツール http://sourceforge.net/projects/pg-rman/ dblink_plus 他のデータベースへ接続するためのモジュール http://sourceforge.net/projects/interdbconnect/ 26
NTT システムとの Fit & Gap NTT システム要件と PostgreSQL の機能マッピング 機能 について 基本的には PostgreSQL で問題なし ただし 1 4の要件がある場合は詳細な検討が必要! NTT システムが必要とする DBMS 機能 PostgreSQL 機能 二相コミット表分割 ( パーティション ) 高可用 (HA 構成 ) CPUスケーラビリティ 1 負荷分散 商用 DBMS 機能 更新処理 レプリケーション 標準 SQL 準拠 2 マテリアライズドビュー デッドロック検知 ロック管理 3 監査 差分リフレッシュ PITR オンラインバックアップ 高速ローダオンライン再編成 4 セキュリティ ログ出力制御暗号化 性能監視 SQL 関数 データベースリンク 27
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 28
NTT グループにおける事例紹介 PostgreSQL 適 事例のご紹介 5 PG-REX 導 事例 可 システムへのPG-REX 導 事例 6 OSSマイグレーション事例 レガシーシステムの更改案件における商 RDBMS から PostgreSQLへのマイグレーション事例 7 トラブルシューティング事例 PostgreSQL でよく陥るトラブル事例 29
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 30
PG-REX 導 事例概要 NTT 網情報を利 者に対してプロアクティブにメールや Web で情報配信する K システム OSSVERT フル活 システム開発 運 コストを低減 RHEL / KVM / Apache / mod_jk / Tomcat / Pacemaker / PostgreSQL / UltraMonkey (+Postfix/Dovecot) Webアクセス3 千件 / 日 メール送信 24 万件 / 日 社内用セグメント 外部用セグメント 社内用 Web/AP1 SMTP1/POP1 DB1 外部用 AP1 外部用 WEB1 待機系 DB サーバ利用によるサーバリソース有効 運用監視 仮想化 仮想化 FW 負荷分散 1 負荷分散 2 ン 仮想化によるサーバ集約 SW 社仮想化 RT 内網社内用 Web/AP2 SMTP2/POP2 DB2 外部用 AP2 外部用 WEB2 ターネット利用 31 イ
PG-REX 導 事例概要 システム要件 (DB に関わる部分のみ抜粋 ) 24H365 運 クラスタ構成によるサービス継続性の確保 サービス停 時間 ( クラスタが切り替わる時間 ) の最 化 DB サーバ構成メリット デメリット 較 採! 方式 案 1 HA クラスタ ( 共有ディスク ) 案 2 PG-REX 概略図 AP サーバ AP サーバ ACT VIP HA (PaceMaker) SBY ACT VIP HA (PaceMaker) SBY PG 共有ディスク PG PG ディスク 同期レプリケーション PG ディスク データ保全性 : データ損失なし ( 単一障害 ) : データ損失なし ( 単一障害 ) フェイルオーバ時間 : 数十秒 ~ 数分 ( リブート時間 ) :10~60 秒程度 ( 検知後即座に切替え ) 復旧手順 : 容易 : スレーブの再構築 ( 手順は確立済み ) 性能 : オーバヘッド微小 : 単体時より10~20% ダウン サポート 実績 : 過去に多数の実績あり 32
PG-REX 導 事例 DB サーバ構成 本システムで採 した DB サーバ構成 DB サーバは性能を考慮し 物理サーバ上に構築バ上に構築 PG-REX によるマスタ - スレーブ構成 ただし スレーブ側も参照クエリの負荷分散先として利 AP サーバ 参照クエリ参照クエリ更新クエリ スレーブ用 VIP DBサーバ ( スレーブ ) マスター用 VIP DBサーバ ( マスター ) DBサーバソフトウェア構成 開発 AP PG-REX Crane (PostgreSQL + Pacemaker) ( 運用監視ミドル ) RHEL ブレードサーバ 参照処理の 切替え時間の短縮 負荷分散 ( 共有 Disk 無 ) 33
PG-REX 導 事例留意事項 PG-REX 導 時の設計や運 で注意すべきポイント NIC の数 レプリケーション再構築 順の確 スレーブサーバ故障バ故障 スレーブサーバのマスター昇格からの切り戻しなど 監視 法 NIC の数 サービス LAN マスター NICが7つ必要! 12 IPMI bonding 3 4 5 bonding 6 7 bonding スレーブインターコネクト1 インターコネクト2 レプリケーション STONITH IPMI 監視 法 マスター 監視サーバ 簡単! スレーブ起動プロセス postgres writer process archiver process wal sender process 起動プロセス postgres writer process archiver process wal receiver process プロセス監視でもマスターとスレーブの見分けはできるが select pg_is_in_recovery(); i f : マスター, t : スレーブ,error :: 障害 34
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 35
サバエンクロジャ社内内OSS マイグレーション事例概要 特定サービスに関する契約情報 ( 申込情報や顧客情報等 ) を管理して営業を 援する M システム 商 製品から RHEL/Apache/mod_jk/JBoss EAP/PostgreSQL に移 し システム開発 運 コストを低減 社網SW 網複数システムを統合する サーバエンクロージャ Web/AP/DB 運用管理 / バックアップ クライアント IT 基盤 他システム 36
OSS マイグレーション事例概要 更改前後のソフトウェア構成 更改前 Web/AP サーバ DB サーバ バックアップサーバ バックアップ 商用バックアップ製品 Agent 商用バックアップ製品 Manager JOB 管理 商用運用管理ソフトウェア M/A WEB 商用 AP サーバ DBMS 商用 DBMS 通信用 AP 商用 DBMS 通信用 AP 商用 DBMS OS UNIX UNIX UNIX 更改後 Web/AP/DB サーバ バックアップ / 運用監視サーバ バックアップ 商用バックアップ製品 Manager JOB 管理 Crane Agent Crane M/A WEB JBoss EAP Apache M/A :Manager/Agent DBMS OS PostgreSQL Linux Linux : 商用製品 :OSS NTT 研究所フ ロタ クト 37
OSS マイグレーション事例概要 マイグレーション実施可否は 最終的には TCO 較で判断 適 性検討 : 機能 性能に関する充 性の確認 移植性調査 : マイグレーションによる影響範囲 修正難易度の確認 単純更改 OSS マイグレーション費 較 費 マイグレーション費用なし TCO 比較 マイグレーション費 適用性検討 移植性検討 設計 製造 試験 マイグレーション費用の見積り精度 OSS マイグレーション費 開発費 保守費 単純更改 OSS マイグレーション H/W ミドル調達費 38
OSS マイグレーション事例適 性 適 性検討における DBMS 課題 既存システムではパーティショニングを利 ティショニングを利 オンライン バッチ性能要件を満 出来るかが不安 実機検証 評価観点オンライン業務 SQL およびバッチ SQL の応答時間が 標値を下回ること 検証条件繁忙期と同程度の背景負荷上で オンライン バッチSQLを発 する. 検証対象 SQL SQL の応答時間を測定 パーティションテーブル (16 テーブル ) 背景負荷 使 頻度の い SQL を並列実 DB サーバ 39
OSS マイグレーション事例適 性 実機検証結果 PostgreSQL で 標性能を満 できることが確認できた! パーティショニングも不要!! No 業務分類対象業務性能目標値 結果 ( パーティション有 ) 結果 ( パーティション無 ) 1 オンライン A 業務 4.9 sec 以下 4.69 sec 2.98 sec 2 オンライン B 業務 01sec 0.1 以下 0.095095 sec 008sec 0.08 3 オンライン C 業務 3.8 sec 以下 3.20 sec 0.86 sec 4 バッチ E 業務 850 sec 以下 787 sec 767 sec 検証環境条件 H/W CPU Intel Xeon 2.66GHz 4core MEM 24GB Strage 146GB 12 本 (VRAID10) S/W RHEL6.2 PosgreSQL9.1( パーティショニング数 16) パーティショニング無しの が性能が良い SQL が存在している 分割キー以外の列を条件としてパーティションをまたがる検索を っているSQL であった 40
OSS マイグレーション事例移植性 移植性検討における DBMS 課題 開発 数が想定よりも増 することによるリスク 既存 AP の修正範囲の きさや修正難易度 対処 法に不安が 移植性調査結果その 1 体規模の 4% 弱の修正で DBMS の移植が可能! 修正規模レポート 調査箇所ソースファイル数ソース行数修正箇所数目視確認箇所数修正ユニーク行数 SQL/DDL Java 約 740 個約 250kL 約 11kL 約 5kL 約 9kL Pro*C 母体規模 db_systax_diff diff で算出 母体規模の 4% 弱 41
OSS マイグレーション事例移植性 移植性調査結果その 2 移植難易度も 全体の 99% が低 1 低 2 調査結果その 1 と合わせ AP 移 に課題がないことが確認できた! 修正難易度レポート全体の 99% # 難易度 SQL/DDL Java Pro*C 1 低 1 4,186 1 11 2 低 2 5,361 798 94 3 中 20 0 0 4 高 0 0 0 計 9,567 799 105 修正例 ( 本事例で最も多いもの ) VARCHAR2 VARCHAR に置き換え ただし バイト数と 字数の差異あり 外部結合演算 (+) LEFT JOIN, RIGHT JOIN, FULL JOIN に置き換え rtrim 関数における空 字の扱いに差異があり 単純置き換えができない 難易度のレベル 低 1: 機械的に直せるもの 低 2: 機械的修正は出来ないが修正がきわめて容易なもの 中 : 機械的修正が出来ず 周辺処理を確認しながら修正が必要なもの 高 : 機械的修正が出来ず PostgreSQLに代替機能がないために検討が必要なもの 42
NTT OSSセンタの活動紹介 1OSS 適 推進 2 ソフトウェア基盤技術 向上 3OSSトータルサポート 4 技術開発 NTTグループにおける事例紹介 5PG-REX 導 事例 6マイグレーション事例 7トラブルシューティング事例 43
トラブルシューティング事例 我々が数多くの障害解析を実施して く中で よく かける PostgreSQL に関わるトラブルを事例としてご紹介します 運 中における突然の SQL 性能低下 運 中に突如 PostgreSQL の性能低下が発 したトラブル 事例をご紹介します PostgreSQLトラブルの未然防 や早期解決の として活 頂ければ幸いです 44
運 中における突然の SQL 性能低下 トラブル内容 毎 あるテーブルの全件レコードを処理するバッチが 突然性能低下し 所定の時間に終了しない 時間 バッチ処理時間 X-3 X-2 X-1 X デイ トラブル原因 ( キーワード ) いつも短時間で終わるのに 今 は全然終わらない 何故?? ロングトランザクション 時間 Commit/Rollback o がなされないトランザクション MVCC VACUUM MultiVersion Concurrency Control: 多版型同時実行制御 不要領域の回収 ( ゴミレコードの再利 化 ) 45
運 中における突然の SQL 性能低下 トラブル発 のメカニズム テーブル 追加 XID 削除 更新 XID 主キーデータ 追加更新削除削除 10 1 北海道 20 25 2 東京 25 2 東京西 30 35 3 名古屋 40 45 4 大阪 ロンク トランサ クションクション TR 1 TR 2 PostgreSQL の物理ページ 不要領域 不要領域 不要領域 不要領域 不要領域 不要領域 不要領域 追加更新追加削除 50 5 広島 60 65 6 福岡 65 6 福岡南 70 7 鹿児島 80 沖縄 : 有効レコード : 不要レコード AutoVacuum ページ単位辺りの有効 が減少 ページ数が増 テーブル肥 化!! ロンク トランサ クションのため回収不可 業務バッチ 処理時間増 全件検索処理シーケンシャルスキャン 46
運 中における突然の SQL 性能低下 対処 法 1 障害事象の確認 対象テーブルに VACUUM VERBOSE を い 以下のメッセージが出るかどうか確認する DETAIL: 200004 dead d row versions cannot be removed yet. 2 ロングトランザクションの確認 ロングトランザクションの存在をンの存在を xact_start の時刻で確認する SELECT * FROM pg_stat_activity ORDER BY xact_start; 3 ロングトランザクションを終了させる クライアント強制終了, pg_terminate_backend() 関数, kill コマンド 4 テーブル, インデックスの再編成 ( 必要に応じて ) ファイルが肥 化している場合は再編成を実施 47
運 中における突然の SQL 性能低下 防 策 ( ロングトランザクション検知 ) pg_statsinfo / pg_stats_reporter PostgreSQL や OS の統計情報を定期的に 動で取得します 48
運 中における突然の SQL 性能低下 防 策 ( ロングトランザクション検知 ) pg_statsinfo / pg_stats_reporter PostgreSQL や OS の統計情報を定期的に 動で取得します pg_stats_reporter ロングトランザクションを捕捉アラートとしてログ出! 49
( 参考 )pg_stats_reporter PostgreSQLの情報を時系列に確認可能です! 50
トラブルシューティング 法 他の DBMS と同じような切り分け 法で OK! 解析に必要な情報の収集 障害事象の確認 PostgreSQL のバージョン (JDBC なども ) PostgreSQL の設定ファイル ログ 実 計画 システム構成 スキーマ情報 など 障害発 前後におけるDBMSの挙動 発 前に何か作業を っていないか? pg_statsinfo/pg_stats_reporter であれば 発 前後の差異を つけることができる かも 51
本 のまとめ 52
本 のまとめ OSSセンタの活動紹介 サポートサービスからみた PostgreSQL の品質 OK! バグ起因のトラブルが少なく 常に安定した運 エンタープライズ 途での PostgreSQL の機能 バージョンアップ毎に着実に進化 商 DBMS から PostgreSQL に移 する AP 移植ツール NTTグループにおける事例紹介 PG-REX 導 や PostgreSQL 移 も実績あり! トラブルも怖くない!? PostgreSQL に合わせた設計 試験 運 を楽にするツールも活 OK! OK! 最後に ぜひ 度 PostgreSQL に触ってみてください! 53
皆様の今後のPostgreSQL 利 の参考になれば幸いです ご清聴ありがとうございました 54