クリスマスの贈り物は高可用性レプリカ2台――ObjectRocket PostgreSQL HAサービス徹底解説

2019年12月12日にObjectRocket.com/blogで公開された記事をもとにしています。

ホリデーシーズンの到来とともに、Rackspace ObjectRocketの歴史における重要な節目から1年が経ちました。2019年のホリデーシーズンに合わせて、私たちはObjectRocket PostgreSQL®サービスに高可用性(HA)を導入しました。ObjectRocketが提供するすべてのデータストアは本番ワークロード向けに構築されており、HAはすべてのお客様にとって必須の機能となっています。

なぜHA(高可用性)が重要なのか?

「HA」という用語に馴染みがない方のために、まずHAがなぜ重要なのかを簡単におさらいしましょう。HAがもたらす3つの主なメリットは以下の通りです。

• ダウンタイムゼロ、または大幅な削減
• データ損失からの保護
• データベースパフォーマンスの向上

データストア間でHAを実現する方法や技術はいくつもありますが、ほぼすべてのHAソリューションに共通する重要な要素がデータレプリカです。ユーザーから見えるのは1つのデータセットまたはデータベースだけですが、その裏側では同じデータの正確なレプリカ(コピー)が1つ以上存在しています。多くのレプリケーション方式において、プライマリと呼ばれるメインデータベースがハードウェア障害、ソフトウェア障害、破損などの問題に遭遇した場合、レプリカがその代わりを務めます。

ここで、ほとんどのHAシステムのもう1つの主要コンポーネントである自動フェイルオーバー機構(他の方式ではプロモーションや選出とも呼ばれます)が登場します。レプリケーションによって健全なデータコピーが複数確保されていても、以下の対応もできる状態にしておく必要があります。

1. プライマリで発生した予期しない問題を検出する。
2. プライマリに昇格させる適切なレプリカを選択する。
3. 障害が発生したプライマリを修復し、新しいレプリカを作成する(昇格させたレプリカの置き換え)。

最後の要素となるのが、リクエストを適切なノードへ振り分ける仕組みです。書き込み時にはプライマリを指すようにアプリケーションを設定するのがベストプラクティスですが、そのプライマリが障害で停止すると、アプリケーションは新しく昇格したプライマリを自動的には参照できません。この問題にはさまざまな解決策がありますが、最も一般的なのはプロキシやロードバランサーを使う方法です。アプリケーションをプロキシやロードバランサーに向けておけば、トラフィックの送信先を自動的に判断してくれるため、アプリケーションを直接データベースサーバーに向ける必要がなくなります。

これらをまとめると、フェイルオーバー発生時には、自動フェイルオーバーシステムとプロキシ/ロードバランサーが連携して動作します。新しいマスターが昇格されると、プロキシやロードバランサーがトラフィックを新しいマスターへ振り向けます。アプリケーション側では何も変更する必要がなく、昇格中の一時的な応答遅延を除けば、アプリケーションは昇格が行われたことさえ意識する必要がありません。以上がプロセス全体の概要です。続いて、ソリューションの各コンポーネントに使用している技術について詳しく見ていきましょう。

使用している技術

主要コンポーネントをおさえたところで、それぞれのコンポーネントをどのように実現しているのかを見ていきます。

レプリケーション

Postgresはネイティブで多くのレプリケーション方式をサポートしています。現在は1〜2台のレプリカを設定できますが、今後選択肢を拡大していく予定です。レプリケーションのもう1つの重要なポイントが、同期と非同期という概念です。同期レプリケーションでは、プライマリは各レプリカが書き込み完了を確認するまで待機してから、書き込みを完了とみなします。一方、非同期の場合、プライマリはレプリカへ書き込みを行いますが、アプリケーションやクライアントへの書き込み確認前にレプリカでの完了を待ちません。私たちのソリューションは同期・非同期の両方のレプリケーションをサポートしており、デフォルトでは同期レプリケーションを有効にしています。環境上のレプリケーション設定では、プライマリのWrite-ahead Log(WAL)への書き込みと、少なくとも1台のレプリカへの書き込みが確認されるようになっています。これらの設定はトランザクション単位またはセッション単位で変更可能です。

フェイルオーバーとプロモーション

フェイルオーバーとプロモーション機能を提供するオープンソースやサードパーティ製のツールは複数ありますが、私たちは以下の優れた特徴を持つPatroniを選択しました。

• Kubernetes®ネイティブサポート: 新しいプラットフォームはKubernetesベースで構築されているため、別途ステート管理や合意形成の仕組みを導入することなく、Kubernetesにそのまま組み込めるツールを採用できる点が大きな決め手となりました。
• 活発な開発とコミュニティ: Patroniを取り巻くコミュニティは非常に活発で、機能の成長に合わせて協力やコントリビューションが可能です。さらに、カンファレンス講演やドキュメント、ZalandoによるOperatorの実装例など、学習リソースも豊富に揃っています。
• シンプルなアーキテクチャ: 他の多くのツールでは、ロードバランシングやプライマリ昇格のためにPostgresインスタンス外の専用リソースが必要になります。PatroniはPostgresをラップし、Kubernetesのネイティブコンポーネントでその他の機能を処理するため、HAのために追加リソースを割り当てる必要がありませんでした。

環境によって結果は異なるかもしれませんが、私たちの経験では、Patroniは設定と保守が非常に容易で、環境に最適なソリューションでした。基本的にはノードがどのHAグループに属するかをPatroniに伝えるだけで、あとはすべて自動的に処理されます。レプリケーションの設定、障害プライマリの検出、レプリカの昇格、新規レプリカの作成、そしてプロセスの最終段階ではKubernetesとの連携まで行ってくれます。

リクエストルーティング

最後に、PatroniとKubernetesのネイティブな構成要素であるサービス(Service)がパズルの最後のピースとなります。Kubernetesのサービスは、コンテナグループ(Pod)のラベルに基づいてトラフィックをルーティングするプロキシのように動作します。Patroniはアクティブなプライマリにmasterラベルを付け、Kubernetesがmasterラベルを持つPodのみにデータベーストラフィックをルーティングします。これは概要レベルの説明ですが、実際の動作もこの通りです。この仕組みは拡張も可能で、セカンダリポートを設けて読み取りリクエストをレプリカへルーティングし、プライマリの負荷を軽減するといった使い方もできます。

以上が導入技術の簡単な紹介ですが、さらに詳しく知りたい場合はぜひお知らせください。お客様との技術談義は大歓迎です。

今すぐ試してみよう!

Mission ControlのCreate an Instance画面では、ステップ2のCustomize Your InstanceセクションにHA設定項目があります。チェックボックスをクリックして矢印を緑色にすると、PostgreSQLインスタンスのHAレプリカが追加されます。右上の省略記号(...)をクリックすると、レプリカの数(1台または2台)を選択できます。

デフォルトでは、障害発生時でも冗長性を確保できるよう2台のレプリカを推奨していますが、1台を選択することも可能です。

ご意見やご質問がある場合は、Feedbackタブをご利用ください。Sales Chatをクリックすれば、すぐにチャットで会話を始めることもできます。