GTM-MML4VXJ
Skip to main content
  1. ホーム >
  2. 製品 >
  3. ソフトウェア >
  4. ライブラリー >
  5. 特集 >
  6. 業務停止はさせない!トラブル時は自動切替えでPostgreSQLの運用を継続(1/2)

富士通の技術者に聞く!PostgreSQL最新技術
業務停止はさせない!トラブル時は自動切替えでPostgreSQLの運用を継続(1/2)
PostgreSQLインサイド

富士通の技術者に聞く!PostgreSQL最新技術 業務停止はさせない!トラブル時は自動切替えでPostgreSQLの運用を継続(1/2) PostgreSQLのエキスパート 谷口康規 20年あまりSymfowareの開発に携わり、SQL言語処理からデータロードコマンド、リカバリ、GUIに至るまで機能開発を経験。鎌内彬貴 2012年に入社してから、GUI(WebAdmin, pgAdmin III)の開発・保守を担当。

企業の生産活動を支えるICTシステムの停止は、いまや生産活動そのものの停止につながるといっても過言ではない。トラブルが起きた際に業務をいかに継続できるか?はデータベースにおける信頼性の重要な要素である。それは「PostgreSQL」をエンタープライズ利用する上で大事なポイントの1つでもある。
富士通では、これに対する解としてSymfoware Serverに搭載されている「富士通版PostgreSQL」に、確実な業務継続を目指す「データベース多重化機能」を実装した。ここでは技術者がどのように機能を検討し開発したのか?縮退を自動で行ない復旧はコマンドひとつでOKという手軽さは一体どのように実現したのか?その真相に迫る。

  • 1
  • 2

次へarrow-double

 [2015年12月4日掲載]

システム規模と価格帯をマッチさせるために

―「WALが損失するという課題の解決」の回で「信頼性」に関わるポイントの1つである「データ保全」の機能について伺いました。「業務継続」は同じく信頼性に関わるポイントですが、それを実現するデータベース多重化機能とはどのような機能なのでしょうか?

鎌内

データベースはICTシステムを支える非常に重要な役目を担っています。このため、データベースの停止は、システム管理者にとって避けなくてはならない重要なテーマです。データベースが停止すると、それを利用している業務システム全体が停止してしまいます。
しかし「形ある物は必ず壊れる(ハードウェアの故障)」し、「人間はミスをする生き物(ソフトウェアトラブル、ヒューマンエラー)」なので、トラブルを完全に避けることはできません。
このような状況から業務システムの停止を避けるために、データベースの複製をリアルタイムに作成しておき、何らかのシステム異常を検知すると自動的に複製されたデータベースに切り替えて業務システムの運用を継続できるようにするのが、当社の商用データベース「Symfoware Server」に搭載されたPostgreSQLで提供しているデータベース多重化機能です。

―オリジナルのPostgreSQLには共有ディスク方式のクラスタリング機能がありますよね?それにもかかわらずデータベース多重化機能を開発したのはなぜでしょうか?

谷口

確かに共有ディスク方式のクラスタリング機能でもデータベースの可用性を高めることはできます。しかし、共有ディスク装置はそれなりに高価です。
また、今でこそ大規模システムでもPostgreSQLが活用されるようになりましたが、PostgreSQLを活用するシステムの多くは中小規模です。このような中小規模のシステムでは共用ディスク装置の価格帯はマッチしないと感じていました。
このため、システム規模と価格帯がマッチする可用性の開発が必要だと考えたのです。

―それがデータベースを丸ごと複製するという機能だったのですね。

鎌内

そのとおりです。データベースを複製するのであれば、共有ディスク装置のような特別なハードウェアは不要です。
例えば社内に2台のサーバが存在していたら、「これを使って高可用システムが構築できる」という感じで手軽に構築できるようになればよいと考えました。それと「運用性/使い勝手としてのオープン」を実現するうえで、クラスタリング機能における導入や運用の複雑さにも着目しました。

―クラスタリング機能における導入や運用の複雑さですか?

谷口

はい。一般的にクラスタリング機能を使うには、データベースソフトウェアに加えてクラスタリングソフトウェアが必要となり、両方をインストール・セットアップしなければなりません。さらに共用ディスク方式の場合は、プライマリサーバとセカンダリサーバの双方から共有ディスクをアクセスできるように設定する必要もあります。
また、システム異常が発生した際の復旧には高度な技術が必要です。
データベースソフトウェアとクラスタリングソフトウェアはとても密接な関係にあるため、それぞれの復旧作業を手順に従って正しく実施しなければなりません。この手順を間違えてしまうとシステム停止につながり、せっかくの可用性を活かせないということが起こります。
この点、私たちが開発したデータベース多重化機能であればクラスタリングソフトウェアが不要になり復旧手順もシンプルになります。

ストリーミングレプリケーションに機能をプラス

―手順がシンプルであれば、システムトラブルのリスクは軽減できますね。ところで、オリジナルのPostgreSQLではバージョン9.0からストリーミングレプリケーション(注1)が実装されていますが、違いは何でしょうか?

谷口

違いと言いますか、そもそもデータベース多重化機能はオリジナルのPostgreSQLに実装されているストリーミングレプリケーションの機能を利用して実現しています。
しかしストリーミングレプリケーションは、データベースを冗長化する機能にのみ特化しています。そのため、システムの異常を検知して自動的に切り替える部分はアプリケーションで実現する必要があります。
この異常検知や自動切り替えにはそれなりのノウハウが必要なため、容易に導入できるとは言い難いのが現実です。そして、ストリーミングレプリケーションにはまさにこの部分が不足しており、私たちが考えるエンタープライズ利用に対する機能が足りていないと感じていました。
データベース多重化機能は、ストリーミングレプリケーションの機能に、当社のノウハウを結集した異常検知機能および自動切替え機能をプラスしてSymfoware ServerのPostgreSQLに組み込んだものであり、業務継続性と運用性を格段に向上させています。

(注1)PostgreSQL 9.0 から実装されたデータベースの複製機能。プライマリデータベースの更新内容をセカンダリデータベースへWALレコード単位に転送してデータベースを複製(レプリケーション)することができる。ファイル単位などの大きな塊ごとに転送するのではなく、データを次々と流れる(ストリーム)ように転送することからストリーミングと呼ぶ。

―ストリーミングレプリケーションの機能強化版ということですね。もう少し具体的に教えてください。

鎌内

実際にサーバを切り替えて業務を継続するためには、どのような障害が起きたのかを検知しなければなりません。障害にはOSまたはサーバがダウンしたのか?無応答なのか?あるいは、データベースのダウンや無応答、さらにはハードディスクの物理的な故障でデータが読み取れないなど、あらゆる事象が想定されます。
この「どこの箇所で、どのような異常が起きているのか?」を検知するエージェントプログラムをプライマリサーバとセカンダリサーバに配置し、データベースを監視・制御しています。
これら監視制御技術は、Symfoware Serverで提供しているデータベースミラーリングによる完全二重化システムの考え方に基づいて、異常検知技術や自動切替え技術を応用したものです。

―ノウハウが必要な監視と制御の部分に実績ある技術が使われているのですね。実際どのように切り替えが行なわれるのですか?

谷口

プライマリサーバに何らかの異常が発生するとエージェントプログラムがそれを検出し、セカンダリサーバのエージェントプログラムに異常が発生したことを通知します。
通知を受けたセカンダリサーバのエージェントプログラムは、プライマリサーバにデータベースの停止を命令します。
プライマリサーバのデータベース停止が確認できたら、セカンダリサーバのデータベースが新しいプライマリサーバのデータベースになるよう状態遷移(セカンダリからプライマリに昇格)させます。
このときに、異常が発生した元プライマリサーバを切り離してシステムを縮退運転させるといった流れになります。

サーバ切り替えの遷移の概要図

【サーバ切り替えの遷移】

―異常が発生したサーバを切り離すのですか?

鎌内

速やかに業務継続するには、異常が発生しているサーバの影響を他に広げないようにすることが重要です。そのためには一刻も早く業務システムから切り離す必要があるのです。
データベース多重化機能では、障害の起きたサーバを切り離して複製されているサーバに丸ごと切り替えるため最新のデータをそのまま利用できます。

―しかし縮退運転となるとアプリケーションは接続先の切り替えを意識する必要がありませんか?

谷口

アプリケーションからは物理的なサーバを意識せずに接続ができる「透過的接続」を実現しているため、切り替えを意識する必要はありません。もちろん、アプリケーションの利用者も切り替えを意識する必要はありませんし、切替え時間は秒オーダーで済みます。
アプリケーションからデータベースを見た場合、異常が発生するとトランザクションはエラーで返却されます。このトランザクションはリトライされるわけですが、このときデータベースクライアントがプライマリサーバやセカンダリサーバを自動的に識別してデータベースに再接続しますのでアプリケーションは何も意識しなくてよいのです。

―ここでも「透過的=アプリケーション開発者が何も意識をする必要がない」を実現しているのですね。

次ページ:「復旧手順の簡易化実現への取り組みや苦労は?」

  • 1
  • 2

次へarrow-double


本ページに記載された内容は、掲載日現在のものです。その後予告なしに変更されることがあります。あらかじめご了承ください。

富士通のPostgreSQLに関する情報がここに「PostgreSQL インサイド」

製品情報

本コンテンツに関するお問い合わせ

Webでのお問い合わせ

入力フォームはこちらから

当社はセキュリティ保護の観点からSSL技術を使用しております。

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)0120-933-200

受付時間 9時~17時30分
(土曜・日曜・祝日・当社指定の休業日を除く)