このページの本文へ

前へ 1 2 次へ

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

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

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

2017年05月17日 07時00分更新

文● 重森大

  • この記事をはてなブックマークに追加
  • 本文印刷

データが飛んだ!犯人は誰だ?……とならないために権限管理を徹底

 三戸さんのセッションは次第に、現場ならではのドロドロした話題が混じり始める。続く話題は、開発担当者とインフラ担当者の分担について。開発担当者とインフラ担当者の壁をなくすというのはDevOpsやCIの目的のひとつだが、あまり良くない方向に働くことが多いようだ。

「声が小さい人やできる人に、多くのタスクが寄っちゃうんですよね。そうならないために、役割分担ができる前提である程度のルールが必要です」(三戸さん)

 その前提でインフラ担当者の立場からChefのレシピを書く場合、まず重要なのは、本番環境にも開発環境にも、開発者がSSHで接続しなくてもデバッグできる環境を用意することだという。ファイルの中間ファイルのアップロード先ディレクトリの指定や、そのディレクトリにどのような権限設定をするのか、社内ルールとして決めておく必要がある。

「開発者にSSHの権限を渡すと、必要なライブラリを勝手に追加したりディレクトリを増やしたりと環境をたっぷり汚してくれるので、インフラ担当者として責任を持てなくなってしまいます。インフラ担当者が環境を把握しておけるように、中間ファイルの置き場など、サーバーがステートフルになってしまう要因も予め固定します」(三戸さん)

 サーバーがステートフルになると、サーバーを再起動した際に同じ環境を保てなくなる。そういう状況を避けるようにしなければならない。では具体的にはどの部分で責任を分解すべきなのかという問いに対して三戸さんは、ベース環境レイヤーとアプリケーション共通レイヤーの間で分けるべきだと主張する。

開発担当者とインフラ担当者との責任分解点はここだ!

「クレデンシャル情報などナイーブな情報に開発者がタッチできないようにすることが重要です。そうでなければ、何かあったときに開発チームを含めて犯人探しが始まり、よく仕事をしている人が矢面に立たされることになります。権限管理をしっかりしておくことで、ごく限られた人がごく限られた手段でしか触れることができないようシステム上で定義しておけば、ドロドロした責任の押し付け合いを避けられます」(三戸さん)

アップデートのタイミングに限ってGitHubが落ちてる問題

 三戸さんの「もっとドロドロした話に進みますよ」という言葉とともに、最後に取り上げられたのは、委託者と受託者の責任範囲という話題。そこには、クラウドならではの課題もあるのだという。

「たとえば、GitHubがダウンしたために契約通りのアップデートができなかったという事案。だいたい外部サービスというのは、クリティカルなときに限って落ちるものなんです。ここで一番問題となるのは、GitHubとの契約関係がないということなんですね」(三戸さん)

更新のタイミングでGitHubがダウン!これ誰の責任?

 クローズドで使いたい場合は、GitHubを受託者の責任範囲で運用するという方法も考えられるが、その場合は開発コストや運用コストに反映されることになる。コストを取るか、外部サービスの信頼性に賭けるか。ここはしっかり委託者と相談して必要ならコストに載せるべき部分ではあるが、それも容易ではないようだ。三戸さんによれば地方SIerは運用を甘く見がちな傾向にあり、「地方SIerは運用で死ぬというジンクスがある」と言う。

 別の契約パターンとしてソースコードをすべて委託者に渡す場合には、委託者側でGitHubを運用してもらうという方法も考えられる。この場合には受託者は売価と引き換えにリスクを逃れることができるが、GitHubを勧めた責任までは逃れられない。

 責任の話とは別に、セッションの締めくくりに三戸さんが語った言葉も、なかなかインパクトが強かった。知識としては理解していても、現場の人が言葉にすると、やはり重さが違う。

「地方だと、AWSを使っても大して安くならないねと言われることも多いです。地方では電源入れたらあとはほったらかしというサーバーが多く、やるべきことをやってこなかったんですよね。それらと比べられちゃうと、コストが下がっていないように見えるのはしかたない。でもそこは、本来やるべきこと、隠れたリスクや隠れたコストを理解してもらうってことが重要なのかなと思います」(三戸さん)

■関連サイト

前へ 1 2 次へ

カテゴリートップへ

この連載の記事