JAWS-UG中国・四国勉強会レポート 第5回

クラウドの開発・運用に関わる責任分界点の話題をたっぷりと

DevOpsの効能とドロドロした現場話をWardish三戸さんが語る

第7回目のJAWS-UG広島で印象的だったのが、3セッション中2セッションがDevOpsに関するものだったということ。以前の速報レポートでも触れたが、懇親会でまでDevOpsの話題で盛り上がった。DevOpsについてプレゼンを行なったのはWardish,LLC.の三戸 鉄也さんとAWSの藤原 吉規さん。内容が濃すぎるため個別記事として掲載するが、それぞれの視点の違いも楽しめるのでぜひ2本合わせて読んでいただきたい。

現場の経験値いっぱいで役立つけれども、記者泣かせのDevOpsセッション

　三戸さんのセッションが始まってすぐに、筆者は焦燥感に駆られた。やばい。これはきちんと勉強して理解してから記事を書かないと的外れになるヤツだ……と。筆者が扱える開発言語はC言語程度で、趣味のプログラミングしか経験がない。手を動かして見ないとと思って自宅サーバなども色々試して来たが、ひとりで環境を用意してそこでひとりで遊ぶだけ。1人で分業体制までは試せないので、DevOpsというものを実感として理解できていないのだ。概念的には理解できていても、現場での生々しい経験談を実感として受け取るのは難しすぎる。

　と、たっぷり言い訳をしたところで、まずは「Vagran＋Chef＋OpsWorksで開発を楽にする！」と題した三戸さんのセッションを紹介していこう。なお以前お送りした記事のように「DevOpsではなくOpsDevであるべきだ」という論もあり、私もOpsありきなのではないかと思っていたりするのだけれど、一般的な用語としてDevOpsを使っていくのでその点に関してはご了承いただきたい。

OpsWorksを使えばChefのレシピから共通環境を簡単に立ち上げられる

　そもそもVagrantとかChefとかOpsWorksとか、題名には筆者の知らない単語しか並んでいない。そんな素人が筆者以外にどれくらいいたかどうかはあやしいが、三戸さんは親切にOpsWorksの説明からスタートしてくれた。

　AWSでアプリケーションをデプロイ、管理する仕組みとして三戸さんはまず、 Elastic Beanstalkを紹介。こちらはアプリケーションを書いてデプロイすれば、下層レイヤーについてはAWSが用意してくれるというもの。サーバーのスケーリングなども気にする必要がなくなる。それに対してOpsWorksは、もう少し下のレイヤーまで自分で自由に設定できる仕組みとのこと。DBを使うのか使わないのか、サーバーの台数は何台なのか、自分で定義した環境を用意してくれる。

「なかでもうれしいのは、Chefに対応してくれているところです。いつも使うサーバー関連の設定を定義しておけば、一括でどーんと用意してくれます」（三戸さん）

Wardish,LLC.の三戸 鉄也さん

　三戸さんはそう言って、実際に自社で使っているOpsWorksのサンプルスクリプトも見せてくれた。スクリプト内ではどういうサービスをどういう順番で起動するのかという手順もChefのレシピとして登録されていた。利用用途によって、指定された曜日や時間に自動的に起動、終了するよう設定もできる。このあたりはElastic Beanstalkでは自動的に設定できるが、OpsWorksなら自分たちの用途に合わせて手動で細かく定義できる。GitHubのリポジトリを登録しておけば、指定したアプリケーションをデプロイするところまで自動化できるので、自社でよく使うサーバー環境を一通り起動した状態ですぐに開発側に引き渡せる。

階層構造を意識したレシピを作成して、責任分担を明確に！

「OpsWorksなどのツールで実現できるのは、開発担当者とインフラ担当者が喧嘩しないですむようにする、開発とインフラの明確な分担です。最低でもアプリケーション固有レイヤー、アプリケーション共通レイヤー、ベース環境、OS、ハードウェアという階層に分けて、それを意識した環境構築を心がける必要があります」（三戸さん）

　この中では、アプリケーション共通レイヤーとベース環境の線引きが難しいようだ。ベース環境に含めるには無理があるが、アプリケーションごとに変わるものではない部分、ということになるようだ。例としてはcomposerやwebpack、Tomcatなど、顧客共通で使われるフレームワークやライブラリ類が挙げられた。

　ではベース環境に含まれるのはどのようなものかというと、Zabbixなど監視ツールの設定やタイムゾーンの設定、ログのローテーションや転送設定、ファイアウォール設定などがこちらに含まれる。さらに、顧客固有のクレデンシャル情報についてもベース環境に含めて定義しておくべきだと三戸さんは言う。連携する外部サービスのアカウント情報やサーバーキーなどがこれに当たる。

OpsWorksを使う際には階層構造を意識して環境を構築すべき

　これらのリポジトリは、アプリケーション開発のリポジトリとは完全に別に管理される。このリポジトリをどう分割するかというのも、運用負荷に大きく影響してくる部分とのこと。しかも、Chefの標準とOpsWorksで使いやすい標準とに齟齬があるというから面倒くさそうだ。

「Chefの標準的なレシピ構成は1つのCookbookにつき1リポジトリが推奨されていますが、OpsWorksではこの構成は使いにくいんですね。複数のレシピセットをひとつのリポジトリに突っ込むのがお勧めです」（三戸さん）

　ではどの部分をセットにするべきなのか。これは案件や運用によりいくつかのパターンが考えられる。三戸さんが紹介したのは、OSレイヤーとベース環境レイヤーをセットにするパターンと、ベース環境レイヤーとアプリケーション共通レイヤーをセットにするパターン。

階層簡略化の例と、それに伴うメリット・デメリット

　前者の場合は、OSのバージョンと各種設定をセットで管理できるというメリットがある反面、ローカルの開発環境と本番環境とレシピを二重管理しなければならないという課題がある。もう一方のアプリケーション共通レイヤーとベース環境レイヤーをセットにする手法は、全社で開発言語が限定されている場合などに効果を発揮するが、何にでも対応しなければならない地方SIerでは言語を限定すること自体が難しいとのこと。