Fastly の認証局向けにレジリエントなデータベースを構築

今回は、新たなパブリック認証局 (CA)「Certainly</u>」が Fastly によって立ち上げられた背景を探るブログ記事シリーズの最新回です。前回は、Certainly を支えるアーキテクチャ関連の決定</u>の一部についてご説明しました。この記事では、システムが定期的かつ自動的に破棄され再構築される、クラウドに似たエフェメラル (一時的な) 環境を作成する決定によって生じた主な課題のひとつを取り上げます。

他の CA と同様に、Certainly の運用の中核にあるのは堅牢で信頼性が高く、レジリエントなデータベースです。巧みに設計された Certainly のデータベースアーキテクチャは、証明書データの効率的なストレージと取得を実現し、ビジネスニーズの拡大を支えるスケーラビリティを提供します。現在 Certainly には MariaDB と InnoDB データベースエンジンが使用され、データセンター間でのデータのレプリケーションが可能です。レプリケーションによりデータの冗長性が確保され、障害発生時に簡単に復旧できるので、運用に対する信頼が高まります。ただし、始めからそうだったわけではありません。MariaDB Replication を採用する前、MariaDB Galera Cluster のセットアップに依存していました。しかしこの環境は手間がかかり、運用上の負担が多く、しかも不安定でした。日々私たちは新たな問題に直面し、最終的に MariaDB Replication への移行が必要になりました。以下は、この決定によってもたらされたメリットの一部です。

1. 複雑性の低減

Galera Cluster のマルチプライマリアーキテクチャでは、同期を行いながらデータの一貫性を確保するために、Certainly の施設全体ですべてのデータベースノード間の継続的な通信が必要でした。一方、MariaDB Replication には、シングルプライマリと複数のレプリカを使用する設計が採用されています。単一のデータベースノードを書き込みプライマリとして動作させることで、セットアップとメンテナンスが大幅に簡素化されます。その上、設定が容易になり、運用に必要なオーバーヘッドを削減できます。複雑性の軽減に伴い、アラートや問題の件数が大幅に減り、その結果 Certainly の SRE (サイト・リライアビリティ・エンジニアリング) チームの効率と士気が飛躍的に向上しました。 

2. 動的なスケーリング

Certainly の公開が近づくなか、ユーザーベースが拡大した際にスケーラビリティが問題にならないようにする必要がありました。Galera Cluster ではマルチプライマリの同期レプリケーションが可能ですが、制約があります。既存のクラスターに新しいノードを追加するのは複雑で時間のかかるプロセスです。一方 MariaDB Replication は、既存のプライマリのオペレーションに影響することなく、必要に応じて新たな読み取りレプリカを追加できる十分な柔軟性を備えています。これにより、チームに負担を与えずに読み取りのオペレーションを水平にスケーリングしやすくなります。

3. ユースケースベースのレプリカ

新しいデータベースの設計により、読み取りのオペレーションやバックアップ、レポート/分析など、ユースケースに基づいて追加のレプリカを作成することが可能です。Galera とは対照的に、ノードの追加や削除によってオペレーションに影響が及ぶことがないので、プライマリは効率を下げることなく機能し続けることができます。

4. 一過性

Certainly は「一過性」のコンセプトを採用しています。これは、データベースノードが一定のサイクルでゼロから再構築されることを意味します。一般的に、一過性はステートレスのコンポーネントに適用され、データベースはデータを保存し、維持するために設計されていると考えられています。私たちは、よりアジャイルでスケーラビリティとレジリエンスの高い革新的なインフラ設計でこのような考え方を打開したいと考えました。前述のように、Galera ではノード同士が継続的に通信状態にある必要があるため、私たちのインフラの一過性とは相性が良くありませんでした。再構築の間、ノードが頻繁にクラスターから削除され再度追加されますが、これによって Galera によるクォーラムの再計算がトリガーされます。これに、バックアップやネットワークの接続性など、さまざまな既知の要因や未知の要素が加わり、予想よりも頻繁に Galera はクォーラムを失い、シャットダウンしました。データベースがダウンすると、Certainly もダウンします。新しい設計では、プライマリノードへの悪影響について心配することなく、リビルドのレプリカを削除できるので、システムを確実に強化することができます。

5. 簡単なフェイルオーバー

フェイルオーバーを管理するのに、オープンソースソリューションの MariaDB Orchestrator を採用しています。このオーケストレーターに関連して、ヘルスチェックや障害検出、パフォーマンス低下の検出、必要に応じてフェイルオーバーを行うツールを作成しました。オーケストレーターによって、各ノードの役割 (プライマリまたはレプリカ) やノード間の関係を含む、データベースクラスターのトポロジーの最新かつ正確な把握が可能になります。このような情報は、フェイルオーバーを管理し、データベースを良好な状態に維持するのに役立ちます。さらに、データ損失やフェイルオーバー中の逸脱の可能性を低減します。

6. 将来的な柔軟性

現在採用しているデータベース設計の高い柔軟性により、常に進化し続ける PKI 業界の環境に合わせてシステムを拡張・変更することができます。

結論を言えば、Galera から MariaDB Replication への移行は、スケーラビリティの強化、パフォーマンスの向上、運用の簡素化につながるきわめて重要な決定でした。さまざまなことを考慮して下したこの選択のおかげで、私たちは新たな課題に適切に対応することが可能になりました。世界中のお客様に向けてサービスを拡張し、進化させるのに必要はツールを得ることができたと、私たちは確信しています。