Ansibleでスケーラブルな負荷検証環境を構築してみた（Playbookでサーバ構成設定編）

はじめに

こんにちは。次世代システム研究室のT.Tです。

最近新規立ち上げのプロジェクトに携わる機会があり、その関連で開発環境と本番環境のイン フラを一から構築する作業の一部を担当することができました。普段は自分でインフラを構築することはあまりないのですが、今回Ansibleを新しく導入してインフラを構築することができたので、その概要とさらに他のプロジェクトでも負荷検証環境の構築に使えるように発展させた内容について数回に分けて紹介していきたいと思います。

Ansibleと構築したシステムについて

まず、Ansibleは構成管理ツールで、YAMLで記述したPlaybookの内容に基づきsshでサーバーの構成を更新することができるものです。

今回はAnsibleを使って、以下のような構成を組みました。サーバーのOSはCentOS 6.5、Ansibleのバージョンは1.7です。

実際のプロジェクトでは開発環境で先に環境を構築して、動作検証した上で本番環境に適用するという流れで作業を進めて、品質が保証された状態の構成を本番環境に再構築、更新するという使い方をしていて、品質の観点ではプロジェクト中にAnsibleの威力を発揮できていたと思います。一方、実際の仕上がったPlaybookは開発環境に適用するか本番環境に適用するかに応じて、同じ設定ファイルを書き換えて対応していたりと、少し危険な運用をしている部分があったり、サービスの負荷が上がったときにサーバーの負荷を検証するところまでうまく考慮できていないところもありました。また、他のプロジェクトで似たような構成で環境を構築する際にもうまく再利用ができないという反省もありました。

改善したシステム構成

そこで本投稿ではさらに一歩踏み込んで、JMeterを組み込んだ以下のような構成を構築できるようにPlaybookをブラッシュアップして、サービスの負荷検証にも対応でき、再利用も可能な資産として活用できるものを目指してみたいと思います。

Playbookのディレクトリ構成としては、各ミドルウェアごとにディレクトリを切って、その配下に以下のような構成で持つ方針です。

production
　group_vars
staging
　group_vars
development
　group_vars
roles

Playbookの開発サイクル

Playbookの開発サイクルは以下のような流れになります。

1. Ansibleのセットアップ
2. Playbookの実装
3. 開発環境へPlaybookを適用
4. 動作検証
5. Playbookの修正
6. 3-5を適宜繰り返し
7. 本番環境に適用

Playbookの開発中は同じPlaybookを何回も同じ環境に適用しますが、yumでのインストールやファイルのコピー等はAnsibleで必要な場合のみ実行するように指定できるので、その点はあまり気にせずに開発を進めることができます。

Playbookの例

最後にPlaybookの例を見てみたいと思います。HAProxyをインストールして起動する例です。以下のようなディレクトリ構成になります。

haproxy_playbook
　site.yml
　roles
　　install
　　　tasks
　　　　main.yml
　　　handlers
　　　　main.yml
　　　templates
　　　　haproxy.cfg.j2
　　　　haproxy.conf.j2

site.yml
- hosts: webservers
  remote_user: root

  roles:
    - install

hosts
[webservers]
localhost     ansible_connection=local

roles/install/tasks/main.yml
- name: install haproxy
  yum: name=haproxy state=present

- name: configure haproxy
  action: template src=haproxy.cfg.j2 dest=/etc/haproxy/haproxy.cfg
  notify:
    - reload haproxy

- name: start haproxy
  service: name=haproxy state=running

roles/install/handlers/main.yml
- name: reload haproxy
  action: service enabled=yes state=restarted name=haproxy

この構成で、HAProxyをインストール済みで設定ファイルを更新した状態でPlaybookを実行すると、hostsに書かれたサーバーの設定ファイルを更新し、HAProxyを再起動します。以下がその実行ログです。

[haproxy_playbook]# ansible-playbook site.yml -i hosts

PLAY [webservers] *************************************************************

GATHERING FACTS ***************************************************************
ok: [localhost]

TASK: [install | install haproxy] *********************************************
ok: [localhost]

TASK: [install | configure haproxy] *******************************************
ok: [localhost]

TASK: [install | configure rsyslog] *******************************************
changed: [localhost]

TASK: [install | start haproxy] ***********************************************
ok: [localhost]

NOTIFIED: [install | reload haproxy] ******************************************
changed: [localhost]

NOTIFIED: [install | reload rsyslog] ******************************************
changed: [localhost]

PLAY RECAP ********************************************************************
localhost                  : ok=7    changed=3    unreachable=0    failed=0

Playbookの簡単な説明になります。

• site.ymlに実行するロールを記述します。
• roles以下に意味のある実行単位で任意の名前を付けて、そのディレクトリ内にtasks、handlers、templatesを配置します。
• tasksにインストールや設定ファイルの更新等の処理、handlersにtasksで更新処理が実行された場合の処理、templatesに設定ファイル等を置きます。
• hostsに適用するサーバーを書きます。
• roles/install/tasks/main.ymlのyumでHAProxyをインストールします(state=presentでインストール、latestで更新)。
• roles/install/tasks/main.ymlのaction: templateでテンプレートエンジンを起動してsrcを処理した結果をdestに配置し、notifyで更新処理が実行されたときに実行されるhandlerを指定します。
• roles/install/handlers/main.ymlのaction: serviceでHAProxyを再起動します。

次回は本番環境や開発環境に適用するためのより複雑なコンフィグレーションを扱うための構成方法を見ていきたいと思います。

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。