てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

システム構築・運用自動化のはなし

はじめまして、開発部のもりと申します。 今回のテーマは、Amazon Web Service(以下、AWS)でのシステムの構築・運用自動化についてです。

AWSではインフラの構築や運用の自動化のサービスとして、CloudFormationやCodeDeployなどいくつか用意されておりますが、ピクスタではChefを用いてシステムの構築・アプリケーションのデプロイが可能なOpsWorksを採用しております。 そこで今回はピクスタでのOpsWorksの活用事例についてご紹介します。

経緯のはなし

これまでのシステムの構築、特にアプリケーションを動かすためのインフラの構築とアプリケーションの運用について、以下のような課題がありました。

  • サーバの構成情報が乏しく同一のサーバ構築が難しい
  • 同じ役割を持つサーバで内部の状態が異なる
  • アプリケーションのデプロイが複雑で属人化している

そこで、インフラの構築と構成管理、デプロイが自動化できて操作もブラウザ上のコンソールで完結できる容易さからOpsWorksを使うことにしました。 あわせてこのサービスをもとにしたデプロイのプロセスを見直すことにしました。

とはいえ、構築手順というものも当初はなかったので、まずはサーバの構成情報の洗い出しと状態定義、特にアプリケーションサーバについてはOpsWorksが標準で用意しているcookbook(以下、Built-in Chef Recipes)だけでは構築が困難であったため、自前でcustom cookbookを用意しレシピに落とす作業からはじめました。

OpsWorksのはなし

OpsWorksとは、AWSのEC2インスタンスで稼働するアプリケーションやミドルウェアを管理するためのサービスになります。他のサービスでもOSやミドルウェアも管理できますが、OpsWorksでは自動化のフレームワークにChefを利用することでデプロイされるアプリケーション(ピクスタの場合、主にRailsのアプリケーション)も管理対象にでき柔軟な制御ができるのがメリットだと思います。 一方で管理対象のサーバにはchef-clientや、Build-in Chef Recipesの適用等で起動までに通常のEC2を起動するより時間がかかりますので、Time-basedでスケールアウトをしたいといった場合は少し余裕をもったスケジューリングをするといった工夫が必要かもしれません。 詳細な内容は「AWS OpsWorks」で環境一式を自動構築が参考になります。

使い方のはなし

基本的な使い方を簡単に説明しておきます。

スタックの作成

レイヤやインスタンス、アプケーションとその動作環境一式をスタックと言います。 ピクスタでは複数のアプリケーションでシステムを構成しており、各アプリケーションでステージングとプロダクション環境をスタックとして作成しています。

レイヤの作成

同じ役割(例えば、Webサーバやアプリケーションサーバ)を持ったEC2インスタンスの集合のことです。 ピクスタでは大抵の場合、「Rails App Server」となりまを選択しています。また、追加するOSパッケージや適用するレシピについてもここで定義します。

インスタンスの作成

レイヤで定義された設定内容に基づき構築されるインスタンスです。 オートスケールタイプはアクセスの流量次第ですが、時間ベースを適用し夜間・休日は構成台数を調整するなどの運用をしています。

アプリケーションの登録

インスタンスにデプロイしたいアプリケーションをここで登録します。 アプリケーションコードはgitで管理しており、リリース対象のブランチを指定しデプロイを行います。

あとは、インスタンスを起動すればミドルウェアの設定からアプリケーションの配備まで自動化されたサーバが出来上がります。 レイヤにてElastic Load Balancerも用意してあげれば、複数台構成で負荷分散も可能になります。

課題を克服したはなし

経緯のところで述べた課題についてOpsWorksを使ってどう克服できたかですが、

サーバの構成情報が乏しく同一のサーバ構築が難しい

→かき集めた構成情報をレシピに定義しレイヤで適用することでインスタンスを削除しても再度作成すれば再現が可能となった。

同じ役割を持つサーバで内部の状態が異なる

→chefの特徴のひとつである冪等性(ある操作を1回行っても複数回行っても同じ結果であるという概念)が内部の状態を収束させることを可能にした。(これはレシピの書き方次第です。)

アプリケーションのデプロイが複雑で属人化している

→OpsWorksのコンソール画面からアプリケーションの登録とデプロイが可能で操作の敷居が低く、運用者のみならず開発者自らバグ修正や機能追加のリリースができるようになった。

CLIを使って自動化を推進したはなし

マネジメントコンソールでの操作と同等の機能がコマンドラインインターフェースでも提供されていますので、周辺システムと連携すると更に自動化が進みます。 ピクスタで活用している事例を2つほど紹介させていただきます。

git pushでデプロイするはなし

先にも述べましたが、ピクスタのサービスを提供するアプリケーションは複数あり、それぞれでステージングとプロダクション環境のスタックが存在します。 各スタックで同じような操作が発生するため、それこそ自動化の対象にすべきということで、エンドユーザには直接影響のないステージング環境については、対象のブランチがリポジトリにpushされたときにgit hook(gitが持っているpushされたときに任意のスクリプトを実行できる仕組み)を使ってOpsWorksのCLIを叩いて対象のスタックに対しデプロイをしています。 これで、コンソール画面をみると自動的にデプロイが実行されていることがわかります。

スプレッドシート駆動構築のはなし

IAMの権限上の理由からOpsWorksの管理画面からの操作ができない方や、マイクロサービスアーキテクチャなどにより、複数アプリケーションとなったシステムの連携した動作を任意のブランチで確認したい場合に、構築したい環境、具体的には構築したいアプリケーションのブランチ名をGoogle スプレッドシートに記載して特定の列に”作成”もしくは”削除”を記載するとApps Scriptとhubotを介して指定の環境一式を構築する仕組みを用意してます。

これはOpsWorksの管理対象のサーバのデプロイ時のプロセスを見るとわかるのですが、バックエンドでOpsWorksのagentを介してchef-clientをwrapperしたシェルスクリプトが実行されており、その際にユーザが定義したメタデータをJSONで渡しています。 スプレッドシートで定義したブランチの情報をAppsScriptからhubotにPOSTし、hubotはさらにそのブランチを引数として先のシェルスクリプトを実行することでagentを介したデプロイをエミュレートしています。 作成者は裏で行っている仕組みを意識せずとも環境ができるので開発者や運用者への作成依頼のようなやりとりがなく作業時間の短縮が図れます。

f:id:texta:20151127193148p:plain

まとめのはなし

OpsWorksの仕組みの理解やchefの学習には少し時間がかかると思いますが、これらの仕組みにより自動化で受ける恩恵は多岐に渡ると思います。これまで属人的であったデプロイ作業がスケールされ開発者・運用者双方で可能となった一方、どこまでを自動化すべきか、特にプロダクション環境への適用は予期しない原因で事故を起こしたときの影響度が高いゆえに、手動で行っている部分もまだあるのが現状です。一定品質を継続的にできる自動化の仕組みはこれからも検討し続けるテーマだと思います。

そんな自動化を進めていくインフラエンジニアをピクスタでは熱烈歓迎します。ご興味のある方は採用ページまたはWantedlyを御覧くださいませ。

recruit.pixta.co.jp