クラウドの開発・運用に関わる責任分界点の話題をたっぷりと
DevOpsの効能とドロドロした現場話をWardish三戸さんが語る
2017年05月17日 07時00分更新
第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に対応してくれているところです。いつも使うサーバー関連の設定を定義しておけば、一括でどーんと用意してくれます」(三戸さん)
三戸さんはそう言って、実際に自社で使っているOpsWorksのサンプルスクリプトも見せてくれた。スクリプト内ではどういうサービスをどういう順番で起動するのかという手順もChefのレシピとして登録されていた。利用用途によって、指定された曜日や時間に自動的に起動、終了するよう設定もできる。このあたりはElastic Beanstalkでは自動的に設定できるが、OpsWorksなら自分たちの用途に合わせて手動で細かく定義できる。GitHubのリポジトリを登録しておけば、指定したアプリケーションをデプロイするところまで自動化できるので、自社でよく使うサーバー環境を一通り起動した状態ですぐに開発側に引き渡せる。
階層構造を意識したレシピを作成して、責任分担を明確に!
「OpsWorksなどのツールで実現できるのは、開発担当者とインフラ担当者が喧嘩しないですむようにする、開発とインフラの明確な分担です。最低でもアプリケーション固有レイヤー、アプリケーション共通レイヤー、ベース環境、OS、ハードウェアという階層に分けて、それを意識した環境構築を心がける必要があります」(三戸さん)
この中では、アプリケーション共通レイヤーとベース環境の線引きが難しいようだ。ベース環境に含めるには無理があるが、アプリケーションごとに変わるものではない部分、ということになるようだ。例としてはcomposerやwebpack、Tomcatなど、顧客共通で使われるフレームワークやライブラリ類が挙げられた。
ではベース環境に含まれるのはどのようなものかというと、Zabbixなど監視ツールの設定やタイムゾーンの設定、ログのローテーションや転送設定、ファイアウォール設定などがこちらに含まれる。さらに、顧客固有のクレデンシャル情報についてもベース環境に含めて定義しておくべきだと三戸さんは言う。連携する外部サービスのアカウント情報やサーバーキーなどがこれに当たる。
これらのリポジトリは、アプリケーション開発のリポジトリとは完全に別に管理される。このリポジトリをどう分割するかというのも、運用負荷に大きく影響してくる部分とのこと。しかも、Chefの標準とOpsWorksで使いやすい標準とに齟齬があるというから面倒くさそうだ。
「Chefの標準的なレシピ構成は1つのCookbookにつき1リポジトリが推奨されていますが、OpsWorksではこの構成は使いにくいんですね。複数のレシピセットをひとつのリポジトリに突っ込むのがお勧めです」(三戸さん)
ではどの部分をセットにするべきなのか。これは案件や運用によりいくつかのパターンが考えられる。三戸さんが紹介したのは、OSレイヤーとベース環境レイヤーをセットにするパターンと、ベース環境レイヤーとアプリケーション共通レイヤーをセットにするパターン。
前者の場合は、OSのバージョンと各種設定をセットで管理できるというメリットがある反面、ローカルの開発環境と本番環境とレシピを二重管理しなければならないという課題がある。もう一方のアプリケーション共通レイヤーとベース環境レイヤーをセットにする手法は、全社で開発言語が限定されている場合などに効果を発揮するが、何にでも対応しなければならない地方SIerでは言語を限定すること自体が難しいとのこと。
この連載の記事
-
第9回
デジタル
もともとサーバーレスな田舎で、もっとAWSを活用していこう -
第8回
デジタル
構成はElastic Beanstalk、監視はCloudWatchを賢く使おう -
第7回
デジタル
Elastic Beanstalk談義についていけなかったJAWS-UG岡山 -
第6回
デジタル
AWSによるDevOpsの考え方とプラクティスをAWSJ藤原さんが例示 -
第4回
デジタル
OpsDevじゃダメ?DevOpsについて熱く語ったJAWS-UG広島 -
第3回
デジタル
AWS導入の説得に失敗し、kintone導入を成功させたエンジニアの話 -
第2回
デジタル
徳島で勝負するサイファー・テック吉田さんが語る地方活性化 -
第1回
デジタル
四国中の濃い人が集まるクラウドお遍路はうどんに負けない歯ごたえ -
デジタル
JAWS-UG中国・四国勉強会レポート - この連載の一覧へ