読者です 読者をやめる 読者になる 読者になる

リクルート住まいカンパニー Tech Blog

ITのちからで暮らしをよくしたい、エンジニア・デザイナーが発信するTech情報メディア

オーケストレーションツールConsulの紹介(1)

f:id:recruit-sumai:20170309104817p:plain

Webアプリケーション屋さんの皆様こんにちは、tomitaです。 今日はオーケストレーションツールConsulを紹介します。

オーケストレーションツールというと色々な側面がありますが、今回はサーバやサービスの”組織化”を支援することでインフラ業務の省力化に繋がるツールとしてconsulを紹介します。

背景 近年の中規模以上のWebサービスはほとんどが対障害性やスケールアウトの観点から複数台のアプリケーションサーバやデータベースサーバから構成されるようになっています。(もちろんSuumoも現在数十台のサーバから構成されています。)

それに加えて、コンテナや仮想化の普及により、運用中頻繁にサーバ台数や構成を変化させることも容易になりました。例えばAWSのオートスケール機能などを使用することでWebサーバの一日の間でも夜間など負荷の高い時間帯のみサーバ台数を増やしてスケールアウトするなどです。ところが構成を容易に変更できる事自体は大きなメリットなのですが、新たな問題が表面化してきました。

  f:id:recruit-sumai:20170328182605p:plain  

問題点 サーバやサービス構成を様々な要件に合わせて頻繁に変更できる事自体は大きなメリットなのですが、面倒なのが構成情報の管理です。典型的な構成情報は以下の様なシステムに属するサーバの一覧表です。

 

ホスト名 IPアドレス サービス 稼働状況 OS
auth-web-01 a.b.c.1 IIS 稼働中 Windows Server 2012
auth-db-01 a.b.c.1 SQL Server(active) 稼働中 Windows Server 2012
auth-db-11 a.b.c.1 SQL Server(standby) 稼働中 Windows Server 2012
bukken-web-01 a.b.c.11 Nginx 稼働中 Redhat Linux
bukken-web-02 a.b.c.12 Nginx 稼働中 Redhat Linux
bukken-web-03 a.b.c.13 Nginx 停止中 Redhat Linux
bukken-db-01 a.b.c.21 MySQL 稼働中 Debian GNU Linux
chintai-web-01 a.b.d.1 Apache 稼働中 Redhat Linux
chintai-cache-01 a.b.e.1 Redis 稼働中 Ubuntu Linux
chintai-mail-01 a.b.e.1 Postfix 停止中 NEXTSTEP
chintai-log-01 a.b.f.1 ElasticSearch 稼働中 BTRON

 

この構成情報は「正確」に実際のサーバ構成と整合している必要があります。なぜなら、この構成情報が以下の様な処理の前提となるためです。

  • サービスやサーバの監視システムへの登録
  • アプリケーションのデプロイや設定変更
  • ロードバランサへの登録
  • サブシステム間連携時のエンドポイント情報

上のような処理はWebサービスの正常運用のために必要不可欠な処理のため、前提となる構成情報がわずかでも実態と乖離していると容易にアプリケーションのデプロイ漏れ、監視システムへの登録漏れなど重大障害の原因となってしまいます。

 

Consulを使うとできること

これらの問題を解決するためにHashiCorp社がリリースしたツールがConsulです。Consulは運用対象の各サーバ上でサービスとして稼働させることで、以下の様なオペレーションを刻一刻と変化する構成情報に合わせて自動的に実施することが可能です。

・サーバやコンテナの作成/破棄に合わせて監視サーバ、ロードバランサへの自動登録/削除 ・サービスの稼働状況に追従して連携するDNSやミドルウェアの設定ファイルへのエントリの追加/削除 ・今この瞬間何台あるかわからないサーバ"群"へのアプリケーションデプロイやコマンドの実行

Consulのアーキテクチャ

Consulは運用対象の各サーバ/コンテナ上で動作するサービスですが、通常は奇数台(3又は5台)のサーバとして動作するノードと多数のクライアントとして動作するノードから構成されます。サーバノードの心臓部は分散KVS(key-value-storage)で、サーバノードの中から自動的に選出されるリーダーノードとそれ以外のフォロワーノードの間でデータがレプリケーションされています。各クライアントノードはこのKVSに対して自分自身の最新のノードとサービスの構成情報を記録するとともに他ノードの構成情報の変更(イベント)に合わせて予め設定された処理を実行します。 f:id:recruit-sumai:20170328182659p:plain 記録された構成情報はRESTやDNSインタフェース又は予め設定したイベントハンドラの呼び出しという形で取り出すことができます。

では、次回はこの分散KVS機能を使ってサーバの組織化を行う実例を見ていきましょう。