古いバージョンのブラウザーを使用しています。MSN を最適にご利用いただくために、サポートされているバージョンをご使用ください。

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

ザテレビジョン のロゴ ザテレビジョン 2017/05/16
DevOpsの効能とドロドロした現場話をWardish三戸さんが語る © KADOKAWA CORPORATION 提供 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.の三戸 鉄也さん Wardish,LLC.の三戸 鉄也さん  三戸さんはそう言って、実際に自社で使っているOpsWorksのサンプルスクリプトも見せてくれた。スクリプト内ではどういうサービスをどういう順番で起動するのかという手順もChefのレシピとして登録されていた。利用用途によって、指定された曜日や時間に自動的に起動、終了するよう設定もできる。このあたりはElastic Beanstalkでは自動的に設定できるが、OpsWorksなら自分たちの用途に合わせて手動で細かく定義できる。GitHubのリポジトリを登録しておけば、指定したアプリケーションをデプロイするところまで自動化できるので、自社でよく使うサーバー環境を一通り起動した状態ですぐに開発側に引き渡せる。 階層構造を意識したレシピを作成して、責任分担を明確に! 「OpsWorksなどのツールで実現できるのは、開発担当者とインフラ担当者が喧嘩しないですむようにする、開発とインフラの明確な分担です。最低でもアプリケーション固有レイヤー、アプリケーション共通レイヤー、ベース環境、OS、ハードウェアという階層に分けて、それを意識した環境構築を心がける必要があります」(三戸さん)  この中では、アプリケーション共通レイヤーとベース環境の線引きが難しいようだ。ベース環境に含めるには無理があるが、アプリケーションごとに変わるものではない部分、ということになるようだ。例としてはcomposerやwebpack、Tomcatなど、顧客共通で使われるフレームワークやライブラリ類が挙げられた。  ではベース環境に含まれるのはどのようなものかというと、Zabbixなど監視ツールの設定やタイムゾーンの設定、ログのローテーションや転送設定、ファイアウォール設定などがこちらに含まれる。さらに、顧客固有のクレデンシャル情報についてもベース環境に含めて定義しておくべきだと三戸さんは言う。連携する外部サービスのアカウント情報やサーバーキーなどがこれに当たる。 OpsWorksを使う際には階層構造を意識して環境を構築すべき OpsWorksを使う際には階層構造を意識して環境を構築すべき  これらのリポジトリは、アプリケーション開発のリポジトリとは完全に別に管理される。このリポジトリをどう分割するかというのも、運用負荷に大きく影響してくる部分とのこと。しかも、Chefの標準とOpsWorksで使いやすい標準とに齟齬があるというから面倒くさそうだ。 「Chefの標準的なレシピ構成は1つのCookbookにつき1リポジトリが推奨されていますが、OpsWorksではこの構成は使いにくいんですね。複数のレシピセットをひとつのリポジトリに突っ込むのがお勧めです」(三戸さん)  ではどの部分をセットにするべきなのか。これは案件や運用によりいくつかのパターンが考えられる。三戸さんが紹介したのは、OSレイヤーとベース環境レイヤーをセットにするパターンと、ベース環境レイヤーとアプリケーション共通レイヤーをセットにするパターン。 階層簡略化の例と、それに伴うメリット・デメリット 階層簡略化の例と、それに伴うメリット・デメリット  前者の場合は、OSのバージョンと各種設定をセットで管理できるというメリットがある反面、ローカルの開発環境と本番環境とレシピを二重管理しなければならないという課題がある。もう一方のアプリケーション共通レイヤーとベース環境レイヤーをセットにする手法は、全社で開発言語が限定されている場合などに効果を発揮するが、何にでも対応しなければならない地方SIerでは言語を限定すること自体が難しいとのこと。 データが飛んだ!犯人は誰だ?……とならないために権限管理を徹底  三戸さんのセッションは次第に、現場ならではのドロドロした話題が混じり始める。続く話題は、開発担当者とインフラ担当者の分担について。開発担当者とインフラ担当者の壁をなくすというのはDevOpsやCIの目的のひとつだが、あまり良くない方向に働くことが多いようだ。 「声が小さい人やできる人に、多くのタスクが寄っちゃうんですよね。そうならないために、役割分担ができる前提である程度のルールが必要です」(三戸さん)  その前提でインフラ担当者の立場からChefのレシピを書く場合、まず重要なのは、本番環境にも開発環境にも、開発者がSSHで接続しなくてもデバッグできる環境を用意することだという。ファイルの中間ファイルのアップロード先ディレクトリの指定や、そのディレクトリにどのような権限設定をするのか、社内ルールとして決めておく必要がある。 「開発者にSSHの権限を渡すと、必要なライブラリを勝手に追加したりディレクトリを増やしたりと環境をたっぷり汚してくれるので、インフラ担当者として責任を持てなくなってしまいます。インフラ担当者が環境を把握しておけるように、中間ファイルの置き場など、サーバーがステートフルになってしまう要因も予め固定します」(三戸さん)  サーバーがステートフルになると、サーバーを再起動した際に同じ環境を保てなくなる。そういう状況を避けるようにしなければならない。では具体的にはどの部分で責任を分解すべきなのかという問いに対して三戸さんは、ベース環境レイヤーとアプリケーション共通レイヤーの間で分けるべきだと主張する。 開発担当者とインフラ担当者との責任分解点はここだ! 開発担当者とインフラ担当者との責任分解点はここだ! 「クレデンシャル情報などナイーブな情報に開発者がタッチできないようにすることが重要です。そうでなければ、何かあったときに開発チームを含めて犯人探しが始まり、よく仕事をしている人が矢面に立たされることになります。権限管理をしっかりしておくことで、ごく限られた人がごく限られた手段でしか触れることができないようシステム上で定義しておけば、ドロドロした責任の押し付け合いを避けられます」(三戸さん) アップデートのタイミングに限ってGitHubが落ちてる問題  三戸さんの「もっとドロドロした話に進みますよ」という言葉とともに、最後に取り上げられたのは、委託者と受託者の責任範囲という話題。そこには、クラウドならではの課題もあるのだという。 「たとえば、GitHubがダウンしたために契約通りのアップデートができなかったという事案。だいたい外部サービスというのは、クリティカルなときに限って落ちるものなんです。ここで一番問題となるのは、GitHubとの契約関係がないということなんですね」(三戸さん) 更新のタイミングでGitHubがダウン!これ誰の責任? 更新のタイミングでGitHubがダウン!これ誰の責任?  クローズドで使いたい場合は、GitHubを受託者の責任範囲で運用するという方法も考えられるが、その場合は開発コストや運用コストに反映されることになる。コストを取るか、外部サービスの信頼性に賭けるか。ここはしっかり委託者と相談して必要ならコストに載せるべき部分ではあるが、それも容易ではないようだ。三戸さんによれば地方SIerは運用を甘く見がちな傾向にあり、「地方SIerは運用で死ぬというジンクスがある」と言う。  別の契約パターンとしてソースコードをすべて委託者に渡す場合には、委託者側でGitHubを運用してもらうという方法も考えられる。この場合には受託者は売価と引き換えにリスクを逃れることができるが、GitHubを勧めた責任までは逃れられない。  責任の話とは別に、セッションの締めくくりに三戸さんが語った言葉も、なかなかインパクトが強かった。知識としては理解していても、現場の人が言葉にすると、やはり重さが違う。 「地方だと、AWSを使っても大して安くならないねと言われることも多いです。地方では電源入れたらあとはほったらかしというサーバーが多く、やるべきことをやってこなかったんですよね。それらと比べられちゃうと、コストが下がっていないように見えるのはしかたない。でもそこは、本来やるべきこと、隠れたリスクや隠れたコストを理解してもらうってことが重要なのかなと思います」(三戸さん) ■関連サイト Wardish JAWS-UG広島

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

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

ザテレビジョンの関連リンク

ザテレビジョン
ザテレビジョン
image beaconimage beaconimage beacon