UPM for Enterprise の高可用性アーキテクチャ
当社のプラットフォームは、多層的なアプローチで高可用性を実現しています：
- 構成可能なヘルスチェックと復旧手順による、自動化されたフェイルオーバーのオーケストレーション
- 地理的冗長性のための、ゾーン間およびリージョン間のデプロイ戦略
- Unit Operator によるインテリジェントなワークロード分散と、リソース使用率の最適化
- リアルタイムの監視と、インシデントの予防的な回避
- ポイントインタイム・リカバリに対応した、バックアップ管理の自動化
プラットフォームの Unit Operator は Kubernetes のネイティブな仕組みと連携し、計画メンテナンス時にも予期しない障害時にも、データの整合性を保ちながらサービスの稼働を維持します。このアーキテクチャにより、エンタープライズのお客様は運用のオーバーヘッドを大幅に削減しながら、可用性の SLA を達成できます。
ミッションクリティカルなデプロイでは、UPM は基本的な Pod の再スケジューリングにとどまらず、プライマリ・セカンダリのレプリケーション、マルチノードクラスタ、複数のアベイラビリティゾーンにまたがる分散システムなど、複雑なデータサービス・トポロジーを高度にオーケストレーションします。
UPM for Enterprise は、革新的な Compose Operator を通じて高度な高可用性機能を提供します。Compose Operator は、Kubernetes や OpenShift 環境で稼働するエンタープライズ・データサービスの高度なレプリケーション・トポロジーとフェイルオーバーの仕組みをオーケストレーションします。
以下のセクションでは、UPM for Enterprise の管理プレーンの高可用性設計とアーキテクチャを、3 つのコアコンポーネントである UPM Platform、UPM Engine、そしてその上で稼働するデータサービスを通じて詳しく説明します。
UPM Platform の高可用性アーキテクチャ
UPM for Enterprise は Spring Cloud フレームワークをベースに開発されており、そのモジュール設計は次の表のとおりです：
| 項番 | 名称 | 説明 |
|---|---|---|
| 1 | upm-control-gateway | Gateway API モジュールは、外部からのリクエストを受け付け、対応するマイクロサービス・モジュールへルーティングします |
| 2 | upm-control-auth | Auth モジュールは、ユーザー認証と権限管理を担います |
| 3 | upm-control-resource | Resource モジュールは、プロジェクト、Kubernetes クラスタ、ノード、ストレージクラス、ソフトウェアなどのシステムリソースを管理します |
| 4 | upm-control-user | User モジュールは、ユーザー情報の管理と操作を担います。 |
| 5 | upm-control-operatorlog | OperatorLog モジュールは、システムの操作ログを記録し、システム操作を追跡できるようにします。 |
| 6 | upm-control-mysql-ms | MySQL サービスモジュールは、MySQL データベースの運用・保守ワークフローの制御と管理機能を包括的に提供します。 |
| 7 | upm-control-postgresql-ms | PostgreSQL サービスモジュールは、PostgreSQL データベースの運用・保守ワークフローの制御と管理機能を包括的に提供します。 |
| 8 | upm-control-redis-ms | Redis サービスモジュールは、Redis キャッシュの運用・保守ワークフローの制御と管理機能を包括的に提供します。 |
| 9 | upm-control-redis-cluster-ms | Redis-Cluster サービスモジュールは、Redis クラスタキャッシュの運用・保守ワークフローの制御と管理機能を包括的に提供します。 |
| 10 | upm-control-kafka-ms | Kafka サービスモジュールは、Kafka イベントストリームの運用・保守ワークフローの制御と管理機能を包括的に提供します。 |
| 11 | upm-control-zookeeper-ms | Zookeeper サービスモジュールは、Zookeeper サービスディスカバリの運用・保守ワークフローの制御と管理機能を包括的に提供します。 |
| 12 | upm-control-elasticsearch-ms | Elasticsearch サービスモジュールは、Elasticsearch 検索エンジンの運用ワークフローの制御と管理機能を包括的に提供します。 |
UPM Engine の高可用性アーキテクチャ
UPM Engine は Operator パターンで開発されており、リーダー選出（Leader Election）の仕組みによってコントローラーの高可用性を確保しています。高可用性設計の詳細は次のとおりです：
- 単一ノードの障害から迅速に復旧し、Operator の継続的な可用性を確保
- リーダー選出により、常に 1 つのレプリカだけがリソースイベントを処理することを保証し、競合状態や衝突を防止
- 迅速なフェイルオーバー機能により、Operator の安定した運用を維持
Operator は、エンタープライズの本番環境で最大限の信頼性を発揮するよう設計されています。冗長性を組み込んだ分散デプロイモデルを採用し、Kubernetes クラスタ全体で複数のレプリカとして稼働します。推奨構成である 3 つ以上のレプリカにより、メンテナンス時間中や予期しないノード障害時にも継続的な運用が確保されます。 高度な Pod のアンチアフィニティ・ルールによってインテリジェントなワークロード配置を実現し、Operator のインスタンスを異なるノードやアベイラビリティゾーンに自動的に分散します。このアーキテクチャにより単一障害点を防ぎ、運用のレジリエンスを維持します。
リーダー選出とフェイルオーバー Operator は Kubernetes の Lease オブジェクトを用いてリーダー選出を実装し、分散環境において複数のレプリカを協調させます。これにより、自動フェイルオーバー機能を維持しながら、常にちょうど 1 つのインスタンスだけが能動的にリソースを管理することが保証されます。
リーダーシップの協調 システムは状態管理プロトコルを用いて、レプリカの動作とリーダーシップの移行を制御します。プライマリとスタンバイのレプリカがヘルスチェックと状態の同期を維持することで、影響を最小限に抑えたシームレスなフェイルオーバーを可能にします。
高可用性の構成
主要なパラメータを構成することで、高可用性の動作を最適化できます：
- リーダーシップのリース期間：リーダーが更新なしに制御を維持できる最大時間を制御
- ヘルスチェックの間隔：障害をどれだけ早く検知するかを決定
- リーダーシップの更新期限：リース更新操作の境界を設定
フェイルオーバーのプロセス
フェイルオーバーは、定められた手順に従って動作します：
- ヘルスモニタリング Kubernetes の Lease オブジェクトを通じてリーダーの健全性を監視します。監視間隔は環境の要件に合わせて構成できます。
- リーダーシップの移行 リーダーが利用できなくなったことを検知すると、リーダーシップの移行プロセスを開始します。スタンバイのレプリカは Kubernetes ネイティブの同時実行制御を通じて協調し、リーダーシップの取得が厳密に 1 回だけ行われることを保証します。
- 状態の調整（リコンサイル） 新しいリーダーは、リーダーシップを引き継いだ時点で次の手順を実行します：
- 管理対象のすべてのリソースを棚卸しする
- 現在の状態を望ましい構成と照合する
- 必要な調整アクションを実行する
- 移行の間を通じて一貫性を維持する
フェイルオーバーは通常数秒以内に完了し、その間も管理対象リソースの厳密な一貫性が維持されます。
高度なスケジューリングと高可用性の設計
UPM は、Kubernetes でローカルストレージを使用する場合の高可用性のために、高度なスケジューリング戦略を実装しています。プライマリノードとセカンダリノードが異なる物理ノードに分散されるようにし、耐障害性を最大化します。
スケジューリングのアーキテクチャ
スケジューリングは、Kubernetes ネイティブの仕組みを活用して Pod の配置を制御します：
- ノードアフィニティ・ルールにより、運用要件に基づいて Pod を特定のノードに配置
- Pod のアンチアフィニティ・ポリシーにより、同じトポロジードメインに複数の Pod がスケジュールされるのを防止
ホストグループの管理
ノードラベル（例：hostgroup=alpha、hostgroup=beta）を用いてホストグループとトポロジーを定義します。このラベリングにより、スケジューラーは異なるインフラ層にわたる Pod の配置について、情報に基づいた判断を下すことができます。
高可用性の戦略
- ノードレベルの高可用性
- kubernetes.io/hostname を用いた Pod のアンチアフィニティにより、プライマリノードとセカンダリノードを異なるホストに分散
- 単一ノードの障害から保護
- 基本的な高可用性要件に最適
- ホストグループレベルの高可用性
- hostgroup ラベルを用いた Pod のアンチアフィニティにより、異なるホストグループへの分散を確保
- ラックやゾーンレベルの障害に対して、より強固な保護を提供
- ホストグループ全体で十分なリソースが必要
障害の検知と復旧
システムは次の仕組みでサービスの可用性を維持します：
- ヘルスモニタリング：liveness プローブと readiness プローブによる継続的なヘルスチェック
- 自動再スケジューリング：ノードが利用できなくなった際に、Kubernetes が Pod を再配置
- フェイルオーバー管理：プライマリノードの障害時に、セカンダリノードを自動的に昇格
このスケジューリング設計は可用性と一貫性の両方を重視しており、インフラでイベントが発生してもサービスの稼働を維持しながら、必要なトポロジー分散を保ちます。
データサービスの高可用性アーキテクチャ
MySQL の高可用性管理
当社の Compose Operator は、Pod のライフサイクルを直接制御することなくレプリケーション関係を管理することで、従来の Kubernetes Operator の枠を超えています。この独自のアーキテクチャにより、次のことが可能になります：
- クラスタ内および外部のデータベースインスタンスのシームレスな統合
- MySQL のプライマリ・セカンダリ・レプリケーション・トポロジーの自動管理
- インテリジェントな Pod のラベリングによる、動的な読み書き分離
- フェイルオーバー時のプライマリノードの自動選出
- レプリケーションの健全性のリアルタイム監視と維持
PostgreSQL の高可用性管理
PostgreSQL のデプロイに向けて、堅牢な高可用性ソリューションを提供します：
- ストリーミング・レプリケーションの構成と維持の自動化
- 同期・非同期レプリケーションモードのインテリジェントな管理
- 高度な WAL（Write-Ahead Log）アーカイブと復旧のオーケストレーション
- フェイルオーバー時のスタンバイ・インスタンスの自動昇格
- レプリケーション遅延と健全性メトリクスの包括的な監視
Redis の高可用性ソリューション
Redis のデプロイに対して、次の方法で包括的な高可用性を提供します：
- Redis のプライマリ・セカンダリ・レプリケーションの自動管理
- Redis Sentinel アーキテクチャとのネイティブな統合
- 自動スロット割り当てによる、インテリジェントな Redis Cluster のオーケストレーション
- クラスタの負荷パターンに基づく、動的なシャードの再配分
- サービスの中断を最小限に抑える自動フェイルオーバー
高度なロードバランシングとフェイルオーバー
UPM の ProxySQL 統合は、高度なトラフィック管理機能を提供します：
- MySQL および PostgreSQL のレプリケーション・トポロジーとのリアルタイム同期
- ProxySQL サーバーグループの自動メンテナンス
- 現在のデータベースの状態に基づくインテリジェントなルーティングルール
- きめ細かなフィルタリングによるユーザーの自動同期
- データベース層全体にわたるシームレスなフェイルオーバーの連携
- MySQL の場合：第一の選択肢として MySQL Router
- PostgreSQL の場合：PostgreSQL ネイティブのコネクションプーリング、または PostgreSQL コミュニティが挙げる選択肢
この推奨はエンタープライズのベストプラクティスに沿ったものであり、データベース基盤の最適なパフォーマンス、信頼性、サポート性の確保に役立ちます。
エンタープライズグレードのアーキテクチャ
拡張可能な Operator フレームワークは、エンタープライズの要件に合わせて設計されています：
- トポロジー管理の自動化による、最小限の運用オーバーヘッド
- 分散したデータベースインスタンス全体での、一貫したデータの信頼性
- 個別のビジネスニーズに合わせた柔軟なカスタマイズ
- 包括的な監視とアラートの統合
- 事業継続のための、手作業不要のフェイルオーバー・オーケストレーション