アプリケーションを開発する前に、計画を立てるのがベストプラクティスです。まず、主なビジネス目標を定義し、要件を収集し、候補となる技術スタックを評価し、統合を理解することから始めます。これは、インフラ のコンポーネントを実装するための青写真として機能し、それらのコンポーネント間でデータがどのように流れるかを定義するものです。
この例では、Galera for MySQLとMariaDBを使用したデータベース設計をレビューします。データベースは、多くのアプリケーションのミッションクリティカルなコンポーネントです。この貴重な資産は、ワークロードを存続させるために冗長性に依存しています。単一障害点があると、ビジネスオペレーション、稼働率契約、そして全体的なユーザーエクスペリエンスに悪影響を及ぼす可能性があります。
リファレンスアーキテクチャをガイドとして、ビジネスの成長に合わせて水平方向に（ダウンタイムなしで）拡張できる、弾力性のあるデータベースとアプリケーションのデプロイメントを構築することができます。
リファレンスアーキテクチャとは？
リファレンス・アーキテクチャは、ソリューションを実装するための共通の設計原則と業界のベストプラクティスを組み込んだ、再利用可能な技術的ダイアグラムです。抽象度の高いクラウド参照アーキテクチャでは、さまざまな計算インスタンス、ロードバランサー、ストレージ、ソフトウェア定義ネットワークなどの間の接続が描かれています。
データベースとリファレンスアーキテクチャ
主な目的は、冗長性を高め、データベースが単一障害点になるのを防ぐことである。この目標を達成する方法は、アプリケーションやワークロードの制約に応じ てさまざまなものがある。例えば、あるアプリケーションでは、一次二次レプリケーションモデルで読み込みと書き込みを分けた方がパフォーマンスが上がるかもしれません。書き込み処理をスケーリングする必要がある場合は、複数のプライマリを使用した戦略が必要になるでしょう。
このほか、データ量、ACID コンプライアンス、フェイルオーバー/選択プロセス（手動または自動）、予想されるクライアント接続数、選択したデータベース技術なども考慮する必要があります。これらの検討事項は、データベースソリューションを形成し、リファレンスアーキテク チャにおいてこれらの要素がどのように連携するかという全体像を形成する。
ガレラの使用タイミング
Galeraは、管理が簡単で、単一のクラウドプロバイダーに依存しない、フリーでオープンソースの高可用性データベースソリューションです。もしあなたのデータベース技術がMySQL、またはMariaDBやPerconaのようなフォークであるならば、耐久性と移植性のあるソリューションとしてGaleraを強くお勧めします。
ガレラクラスターの優位性
- Node Failures- ノードに障害が発生した場合、プライマリコンポーネントを選出するために重み付きクォーラムを呼び出すことによって、スプリットブレインの状態を防止します。
- マルチプライマリ、アクティブ-アクティブクラスタ- クラスタ内の任意のノードに対して読み取りと書き込みを行います。
- データの一貫性- 認証ベースの同期レプリケーションを使用し、ACID準拠を保証します。
- 自動ノードプロビジョニング- 障害ノードが回復したとき、または新しいノードがクラスタに参加したとき、SST（State Snapshot Transfers）またはIST（Incremental State Transfers）を使用して、プライマリコンポーネントの状態と自動的に同期させます。
ガレラクラスターの制限事項
- MyISAM をサポートしない - InnoDB エンジンのみをサポートします。システム・テーブルを含む他のテーブル・タイプへの書き込みはレプリケートされません。
- テーブルのフォーマット- 主キーのないテーブルは 削除できないし、適切に複製もできない。
- ロジックの検討- 明示的なテーブルロックの使用を避けるために、アプリケーションロジックの書き換えが必要になる場合があります。
- 書き込みのスケーラビリティ - すべてのノードはコミットする前に書き込みが可能であることを証明する必要があるため、クラスタが大きくなると書き込み性能は低下します。クォーラムと最適な書き込み性能を確保するために、クラスタサイズを3ノードに抑えることを推奨します。
シングルポイント・オブ・フェイルの排除
従来のLEMPスタックを例にとると、アプリケーションソフトウェアとデータベースは、将来のスケールに備えて異なるコンピュートインスタンスに分離されています。このようなセットアップは次のようになります。
懸念事項の分離はベストプラクティスであり、確かにスケーラビリティのサポートに役立ちます。しかし、冗長性がないため、データベースとアプリケーションサーバーの両方が単一障害点になってしまいます。この構造を改善することで、そうした単一障害点を排除し、全体的なリファレンスアーキテクチャを構築することができるのです。
VLAN & クラウド・ファイアウォールによるシンプルなガレラクラスターのセットアップ
Galeraクラスターは、データベースレイヤーを3ノードに増やし、ノード間で同期レプリケーションを行います。LinodeのVLAN 、パブリックネットワークや共有プライベートネットワークからのレプリケーショントラフィックを分離し、Cloud Firewall 、外部からのアクセスを制限するVLAN 。 GaleraノードはフローティングIPアドレスを共有するため、1つのノードに障害が発生しても、もう1つのノードが知らないアプリケーションサーバーへのリクエストを引き継ぐことができる。
これでデータベース層は高可用性になりました。次に注目すべきは、アプリケーションサーバへの対応です。このプロセスは ステートレスのアプリの場合は、さらに考慮する必要があります。 ステートフル.状態の維持方法によっては、コードのリファクタリングや、Unisonや Glusterなどのツールによるファイルレプリケーションの実装が必要になるかもしれません。この例では、一時的なセッションファイルを除いて、アプリケーションの状態はデータベースによって維持されていると仮定します。
ロードバランシングとアプリケーションレプリケーション
ロードバランシングはアプリケーションに高い可用性と水平方向のスケーラビリティを与えますが、単一のロードバランサーインスタンスは単一障害点を生み出します。冗長性はこの実装の重要な要素です。LinodeNodeBalancers は、セッションのスティッキネス、ヘルスモニタリング、クライアントリクエストのバックエンドアプリケーションノードへの分散を容易にする、高可用性のすぐに使えるソリューションを提供します。
一方のアプリケーションサーバーがダウンした場合、NodeBalancerは健康なノードにのみトラフィックを誘導するようになります。不健全なノードが回復するとすぐに、以前と同じように接続のバランスを再開します。このため、ダウンタイムなしにアプリケーションサーバーの追加、削除、更新を簡単に行うことができます。また、Galeraが提供するアクティブ-アクティブソリューションにより、どのアプリケーションノードもどのデータベースノードに対しても読み取り/書き込みを行うことができます。
Linodeのソリューションエンジニアリングチームは、ベストプラクティスを念頭に置いてアプリを開発するために、このようなフレームワーク、ガイド、ツールを共有しています。Galeraクラスタが提供する高可用性の利点について、詳しくはこちらをご覧ください。Linode上で構築を始める準備ができたら、Galeria、Debian 、Ubuntuを使ってMariaDBクラスターをセットアップするためのガイドをチェックしてください。
コメント