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

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

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

• 【関連特集】WALが損失するという課題の解決

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

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

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

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

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

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

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

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

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

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

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

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

• Symfoware Server 製品情報

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

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

図：サーバー切り替えの遷移

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

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

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

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

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

先ほど、トラブル発生時にはサーバーを切り離して縮退運転を行なうと伺いましたが、縮退運転からは早急に復旧することが大切だと思います。この点について、何か取り組まれているのですか？

谷口
復旧手順の簡易化を実現しています。サーバーの切り替えは自動的に行なわれるのですが、復旧は人が作業しなければなりません。この大事な作業において、複雑な手順というのは二次的なミスにつながりかねません。このため、復旧手順をできるだけ少なく、分かりやすい操作になるように設計しました。

手順自体が少なければミスもその分減らせますね。具体的にはどういう手順なのでしょうか。

鎌内
最初にトラブルの基となった原因を解決する作業を行ないます。ハードウェアが故障したのであれば該当するハードウェアを新しいものに取り換えたり、プログラムがダウンしたのであれば修正やパッチの適用、パラメーター修正などの処置を行なってから該当するプログラムを再起動したりといった作業です。その作業が済んだら、切り離した元プライマリーサーバーを復旧させるのですが、その操作は"コマンドひとつ"で終わります。

コマンドひとつですか？

谷口
はい、コマンドひとつです。ストリーミングレプリケーションにおける復旧作業では、プライマリーサーバーとセカンダリーサーバーに存在している環境設定ファイル「postgresql.conf」の内容を修正したり、新しく組み込み直すセカンダリーサーバーにリカバリー設定ファイル「recovery.conf」を作成したり、異常発生前のディレクトリ構成を復元するといった、それぞれのサーバー間を行き来するいくつかの作業があります。データベース多重化機能では、切り替え後のプライマリーサーバー（元セカンダリーサーバー）に存在している各種設定やデータと同期させるといったこれらの作業をコマンドひとつに集約しました。

複数の作業をコマンドひとつにまとめるということは容易ではないように思いますが、開発は苦労されたのではないでしょうか？

鎌内
復旧コマンドの仕様については、かなり議論を重ねました。「コマンドひとつで」というコンセプトはすぐに決定しましたが、いざ仕様を決める段階になるとオプションをどこまで用意するべきなのか悩みました。 きめ細かに設定できた方がよいと考えると指定できるオプションは増えていきます。しかしそれは設定項目が増えることにつながり、ひいては複雑になってしまう原因となるので当初のコンセプトと"ずれ"が生じます。逆にオプションを極力削ってしまうと簡単にはなりますが、そもそも本来の機能としてどうなのか？というところにつながってしまうので落としどころを見つけるまでに議論を重ねました。

使いやすいと簡単に見える印象がありますが、その裏にはいろいろな苦労があるのですね。

谷口
そうですね、特に異常検知機能と自動切替え機能の開発作業は苦労しました。一口に「異常」といってもさまざまなパターンがあります。異常を検知するため各サーバーに対して、データベースプロセス監視、ディスク監視、ペアとなるサーバーの死活監視（OSの監視）を担う3つのスレッドを用意することで、自分自身と相手を常に監視するようになっています。そしてこの3つの監視スレッドを制御しながら、ペアとなる相手サーバーとの整合性を保証する制御機構も用意することで、確実に異常を検知できるように設計しています。加えて、エラー事象ごとに「切り替え対象とするのか？」「切り替えは行なわずエラーを通知するだけにするのか？」といった分類にも非常に時間をかけました。

図：異常を検知するさまざまな仕組み

先ほど、異常検知と切り替えのノウハウはSymfoware Serverから応用したと伺いましたが、その開発時にエラー事象の分類を実施したのではないのですか？

鎌内
もちろん、実施しました。しかし、データベース多重化機能は先に開発されたSymfoware Serverのデータベースミラーリング機能とコンセプトや実現する機能は同じなのですが、ベースがPostgreSQLのため全て流用できるとはいきませんでした。正確にいうとコンセプトを基にしてゼロから作りこむイメージです。なぜなら、PostgreSQLの挙動は事象ごとにSymfoware Serverと異なります。このため、パターンをマトリックス化して1つ1つプログラムを追うだけではなく、実際に事象を再現して確認しながら開発しました。これはとても大変でした。

そういった地道な作業が"簡単に運用できる"というところにつながっているのですね。今後強化したい点はありますか？

谷口
強化したい点は2つあります。1つは「信頼性のバリエーション強化」です。現在、データベース多重化機能で実現しているのはSymfoware Serverに搭載されているデータベースミラーリング機能と同様の1対1完全二重化システムです。もちろん、この1対1でも信頼性は十分に確保できると考えています。例えば、データベース多重化機能と遠隔地レプリケーションを組み合せて運用することで、災害対策も兼ねた多重故障に対応できるシステムを構築することもできます。ただ、信頼性の要件はシステム用途に応じていろいろあります。現にオリジナルのPostgreSQLに搭載されているストリーミングレプリケーションは1対Nに対応しています。これを活用して今後は1対Nのデータベース多重化機能、つまり1台のプライマリーサーバーのデータベースを複数台用意されたセカンダリーサーバーのデータベースに同期反映できる機能を実現したいと考えています。これにより、利用者の多重故障に対する信頼性の選択肢を増やしていきたいと考えています。

信頼性の選択肢が広がれば、PostgreSQLの活用範囲もさらに広がりますね。もう1つはなんでしょう。

谷口
「導入のしやすさ」を向上することです。CUIだけでなく、GUIによる視覚を活用した直感的な操作で、データベース多重化機能のセットアップ作業や復旧作業を実施できるようにしたいと考えています。データベース多重化機能はストリーミングレプリケーションをベースにしているため、ストリーミングレプリケーションのセットアップに関する知識が必要です。残念ながら、現状ストリーミングレプリケーションのセットアップは少々複雑なのです。このセットアップ作業がGUIで行なえれば、これまでストリーミングレプリケーションをセットアップしたことのない技術者でも簡単にセットアップできるようになります。同様に、サーバーの状態確認や復旧作業もGUIで直感的に操作できれば、データベース専任の作業者でなくても運用できるようになります。このように「運用性／使い勝手としてのオープン」を具現化した、誰でも容易に高信頼なシステムを利用できることを目指した運用性向上に取り組んでいきたいと考えています。

エンタープライズ用途であっても「運用性／使い勝手としてのオープン」を目指すことで人に優しいソフトウェアを実現していくのですね。

2015年12月4日掲載