構築事例

OSS

AWS上でのクラスタ化

クラスタ化の概要

AWSのようなパブリッククラウドのIaaS、PaaSサービスでは、クラウド事業者側の仕組みでシステムの冗長性がある程度は担保されています。しかし、こうした担保はハードウェアレイヤーに限られています。残念ながら、パブリッククラウド側でアプリケーションが正常に動作していることを監視することはできません。そのため、重要なサービスを提供する場合には、AWS上でもクラスタソフトウェアを使った冗長構成が利用されています。

クラスタ化のポイント

AWS上でクラスタサーバを作る場合には、次のような点を考慮する必要があります。

サービス用アドレスの切り替え方法

AWSでは、サーバに自由にIPアドレスを割り振ることができません。そのため、クラスタソフトウェアが用意している仮想IPアドレスを割り当てる仕組みを、そのまま利用することができません。

データの共有

AWSでは、NFSやRDBなどはクラウドサービスとして提供されています。こうした仕組みは強固に冗長化されているため、それを上手く使ってデータ共有を行うことが望ましいです。一方で、アプリケーションのデータを冗長化するためには、NFSやRDBだけでは不十分な場合もあります。そのような場合には、DRBDなどの仕組みを使ってデータを冗長化することを検討します。

リージョンとアベイラビリティゾーン

クラスタを構成するコンピュータが、物理的に同じハードウェア上に存在していることは好ましくありません。また、より重要なサービスでは地理的にも異なるロケーションに配置することが好ましいと考えられます。一方で、DRBDを利用する場合には、データを共有するサーバ間ではレイテンシーが一定以下になるように構成する必要があります。通信の遅延が発生すると、データの同期を取りつづけることが難しくなってしまうからです。

クラスタシステムの構築例1

次は、AWS上でLDAPサーバを冗長化した場合の構築例です。構築例2に比べて、サービス停止の検知が早い方法です。

  • クラスタソフトウェアを使って、稼働系サーバでLDAPサービスが動作するように設定を行います。
  • クラスタソフトウェアから、LDAPサービスが適切に稼働していることを監視します。
  • サービスIPアドレスの設定は、稼働系サーバのIPアドレスをグローバルNATと連携する方法で行います(AWSのAPIを利用して、クラスタソフトウェアからグローバルNATを設定します。)
  • LDAPのデータ領域をDRBDで共有します

図:クラスタシステムの構築例

クラスタシステムの構築例2

次は、AWS上でLDAPサーバを冗長化する場合のもう一つの構築例です。構築例1に比べて、サービス停止の検知から切り替わりに時間がかかります。

  • クラスタソフトウェアを使って、稼働系サーバでLDAPサービスが動作するように設定を行います。
  • クラスタソフトウェアから、LDAPサービスが適切に稼働していることを監視します。
  • LDAPサービスをELBに設定し、2台のサーバに負荷分散する設定を行います。
  • ELBでは、ldapポートのサービス監視を設定します。

図:クラスタシステムの構築例

OSSでクラスタ化するメリット

AWSの冗長化の機能だけでは、アプリケーションレベルで正しく動作していることまでを監視することができません。OSSのクラスタソフトウェアを利用することで、リーズナブルな費用で、サービス監視までを実現することができます。

AWSで用意されていないサービスも冗長化できる

RDB、ElasticSearch、NFSなど、AWSでは高度な冗長化を提供するサービスメニューが用意されています。OSSのクラスタソフトウェアを上手く使うことで、それ以外のアプリケーションや独自ソフトウェアのデータなどを冗長化することができます。

サービスの監視や切り替えを自由に設計できる

AWSでは多くのAPIが公開されています。OSSのクラスタソフトウェアでは、こうしたAPIを活用して、サービスの監視や切り替えの仕組みを自由に構築することができます。公開されているAPIを、フル活用することができます。

サービス費用の削減

ELB、RDB、ElasticSearch、NFSなどのAWSのサービスを利用すれば、高度な冗長性を手に入れることができます。ただし、それには別途費用が毎月必要になります。クラスタは、最小2台のノードがあれば構成することができます。そのため、小規模なシステムではむしろ割安になる場合もあります。

クラスタ化の注意事項

AWSでのクラスタ化では、次の点に注意する必要があります。

  • ノード間のレイテンシー
    DRBDは、通信の遅延(レイテンシー)には非常に敏感です。そのため、リージョンとアベイラビリティゾーンを適切に選び、あまり遅延が大きくないことを確認しておく必要があります。
  • 監視のタイムアウトやリトライは緩めに設定する
    AWSに限らず、クラウド環境では公開されていない小さな障害が頻繁に起こっているようです。ただ、そうした障害は自動的に復旧され問題になることはありません。しかし、ping監視などを厳しく設定していると頻繁にクラスタが切り替わりを起こしたりする原因になります。
  • ベンダー選定
    AWSの専門ベンダーでもクラスタに詳しいとは限りません。AWSでのクラスタ化を検討する場合には、クラスタソフトウェアに詳しいベンダーを選択することをお勧めします。

その他の構築事例