運用を考える必要なんて無いというお客様もたまにはいますが、日経BPの「企業情報システムの運用管理に関する実態調査」(2013)で、45%、保守を含めれば75%が、企業のIT関連校ストになっているという結果になっていて、企業のITを運用抜きでは語れないということで、このパネルを企画することになりました。
パネラー紹介
運用設計ラボ合同会社 波田野様
去年12月から本格的にAWSを触り始めました。セキュリティ方面で色々見ていこうと思います。低レイヤーの運用からこの世界に入りました。レガシー運用、運用でカバーというと私が上から2番め。ダメな話は私がさせていただこうと思っております。
HiganWorks LLC 澤登様
Infrastructure as codeに感銘を受け、Chef活用ガイドなど執筆。OpsWorksの解説も依頼され、今日はそのような内容を話しできれば良いと思う。
株式会社ネットプライスドットコム 今井様
いまは新規事業を沢山立ち上げる部門に居ます。どのように運用まで見越した設計をするかという視点を持っています。どちらかと言うと小さな会社でサービスをスタートさせていくような視点で今日はお話させていただきたいと思います。
波田野 運用の現状
運用でカバーに至った遍歴をお話します。2009年ごろから理想の運用を追い求めて始めました。最近は社会基盤とも言われるのでサービスが安定すること、業務不可が平準化すること、運用に対する評価の適正化、つまり安定した運用楽な運用稼ぐ運用ができたら良い。
テレコムアイザックさんと研究させていただくなどしていろいろな現場の話を聞いてきた。
業務が多岐にわたり全てを把握することが困難になっている
業務の設計思想が失われていて、、、
人が育たない優秀な人が入ってこない定着しない
Internet Week 2009 運用現場における典型的な声
実は運用現場の悩みは共通していることがわかってきています。
そしてそれが自分たちの努力不足で起きていると考えている現場の人が多い。
その中で見えてきたが人によって運用という言葉の概念が違う。運用に対する予算がない、何かあると運用費で持って行かれたりしてしまう。その他ドキュメントが無かったり属人化されていたり。
運用とは本来活用という意味。運用カバーっておかしな言い方ですよね。
高負荷、属人的、見えぬ費用対効果というのが概ね共通した原因かなと思います。
費用対効果については予算権限がなくてどんどん減っていく。こんなの日本だけじゃないのかという話があって話もしたいですがそれは別の機会にしたいと思います。
今井 スタートアップのサービス開発
リーンスタートアップという書籍が大きな影響を与えている。
大きな設計、地図ではなく、測定可能な一番小さなプロダクトを作ってお客さんの声を聞いてどんどん変化していこう、方向を決める、コンパスを見る開発というのが増えています。
少人数での立ち上げ、若手中心の経験の浅いエンジニア、Agileでイテレーション周期が短い、ビジネスの懸賞を優先。
そこで課題として運用が考慮されない、属人的になりがちという課題がある。
・MVP 20日ぐらい、
☆設計の課題
・プロトタイピング
・プロダクト開発
☆DevからOpsへの引き継ぎ
・継続的開発・運用
圧倒的に長いのは運用なのにそこが検討に乗ってない。3つも4つも並列でプロジェクトを回している中で、全体を集中して管理したほうがいいのか、それぞれ個別に自立するのが良いのかという話になるが、結果的に言うと、自律型を目指すとオレオレ環境属人的になる。
モバイル時代も沢山のコンテンツサービスを作っていたが、20、30回す中で、運用へ引き継ぐときに課題を感じる。
澤登 こんないい世界もあるよ
Public/PrivateIaaSとInfrastructure as Codeで効率を上げる
インフラの構成をプログラムで管理する。APIによるサーバー調達と構成管理
管理対象の動的取得、Chefなどで構成情報も継続更新。コードには再現性がある。人による失敗も少ない。テストしやすい。環境も移行しやすい。
継続的に今の情報をいつでも取れるようになってくる。
そうするといままで効率が悪かった所が少なくなって安定するのではないかと思う。
そして再現性があるのが一番のメリット。
再現性があるということは今ある環境をもう一つ別の環境に、全く今とお謎構成で再現してテストをする、変更したらどうなるかを試す、というのを複製した環境で試すことが出来る。
開発用環境と本番用環境でスケールやパフォーマンスが違うということもあるが、一緒の環境を作って試したり、あるいは開発のほうがパフォーマンスのいい環境を作ってしまって高速に開発をするといったことも出来る。
自動化は運用を救うのか
荒木
Chefさえ使えば少人数で回せる、という話が出てくるが、本当に自動化で運用は救われるのでしょうか。
自動化自体は運用の歴史の中で何人もの人がやってきたことだと思うのですが、今在でどうしてうまく行かなかったのでしょう
波田野
自動化の最大の問題点は自動化されたものだけが残っていて、なぜ自動化されたのかが引き継げない。部署異動するたびに自動化ツールのメンテナンスが必要とか、退職した人の自動化ツールを引き継いだものの、という問題も発生するので、単純に自動化する姿勢には懐疑的な姿勢でいる。
運用はドキュメント駆動にしていかなければならないと考えている。
書くということは物事を整理する重要なきっかけとなる。整理していくことがまずレベル１。
次に有形の成果物となることで客観化されていくレベル２。
そして時と空間を超えて治験が共有される脱属人化がかのうになるレベル３。
自動化は脱属人化までいって初めて実現できるものであると考えている。ドキュメント化によって事業設計をしないと自動化まで行けない。自動化はいいことだが目的ではないということに立ち返っていただきたい。
自動化されたものはそれ自体の保守が自動化するとか、自動化された業務の仕様が不明になり業務プロセスが硬直化する。自動化された業務でトラブルが発生すると、手動ではデプロイができなくなる。
澤登
クラウドを使っていく上での運用は設計をしっかりやっていかなければならないと思う。
設計の前提条件、今まで物理サーバーで設計していたのをクラウドに持って行ってもうまくいかない。じゃあクラウドダメだ、ではなくて、各コンポーネントの独立性（疎結合）を担保してひとつぐらい落ちてもいいような設計をしていかなければならない。
そういうことは上流工程からクラウドに最適化した設計をしていかなければならない。
ER図上でも良いし、PaaS使ったりSaaS使ったりしてもよいし。今までのプライベートな環境と同じじゃなくてもいいよ、っていう作り方を勉強するなりリサーチするなりして、今まで同じシステムで運用負担がかかっていたのが減少すると思う。
サーバーの替えがきくということを活かした障害対応をフローにして作っていけば運用フェーズに入った後も、楽になっていくのではないかと思う。
開発自体も仮想環境でやるようにすれば、本番もクラウドに移しやすくなるのではないか。
DevとOpsの話し、私はもっと垣根を減らしていくべきだと考えていて、だいたいDeveloperさんの方からやっていきたいという考え方がある。
インフラ要素をコード化、コードの実行で環境が構築できる、各種ツールとのインテグレーションが可能で、開発初期段階から本番環境での課題も見えやすくなり、運用してみて気づいたというようなことをなくしていくことができればよいのではないかと思う。
誰がいつなぜやったのか、インフラ管理がコード化されていれば、いつ誰がどのような経緯で変更を加えたんかをコミットログで追うことができるようになる。
荒木
綺麗にコミットできないというのが往々にしてあるけれどもそういうことにたいするアプローチはあるでしょうか。
澤登
Githubでissuesなど使えばどういう問題にどういう対処がなされたのかは置いやすくなると思います。
今井
- 学ぶモデルとしてのインフラ構築が出来ないか、よく考えられた環境には理由がある。設計がなぜなされたのか、デザインパターンの意味を知るようにしましょうと。
- ベストプラクティスをコードで残していく、再現性があると強い。時間がなくてマニュアルとコードのどちらかしかなかったらコードを取る。
- 開発・運用の悪癖を環境による制約で防いでしまう
- 環境についての理解が浅くても運用を回せる状態にする。
とはいったものの、自動化環境を作っていけるのか？AWSの世界が広すぎてそんなの全部設定していけるのか？
ということで環境を作った。CloudFormationとOpsWorksのAPIラッパーを作成。Railsの本番とステージング環境がぱっと出来るようにした。次の案件で使おうと思っていたのに。。。
ところが大型案件の言語PHPみたいなことになってしまった。
そこで、Githubで用意していたコードを拡張していって新しい環境に合わせたものを作った。
荒木
小さなチームになると運用エンジニア、デヴェロッパなどと別れる時代ではなくなっていくと思う。そうした中で運用エンジニアに求められることとは…？
今井
Opsに渡してからの話をします。
とりあえず渡して、OpsWorksを使っているので、インスタンスの追加ぐらいはできるので最低限の運用ができる。というわけで簡単だから、とだますかのように渡した。これで簡単だから！と。
本番を手で変えちゃうと後でデプロイしたらひどい目に合うということを学習して、自分でレシピを読むようになっていく。
その中で、ベストプラクティスが人を育てたとぼくは思っている。
わかっている人に構築させて、それを運用していく人がベストプラクティスを理解していくことになる。そういう形でのエンジニアの育成、僕達が持っているベストプラクティスが人を育てるということが出来るようになっていくと思っている。
荒木
というと、学ぼうという意識を持っていないひとはもう知らないということでしょうか
今井
強制的に運用に放り込むのも有りだと思う。運用の要求の中で迫られてこのフローに入ることになって学んでもらって、やがてひとつに伝えられるように育っていくという流れ。
澤登
耐障害性や復旧フローにはとてもこだわってインフラを構築していた。それをクラウドに持っていくとなくなっちゃうのかというと、クラウドベンダも同等のこだわりを持っているはずである。
普通にハードウェアで作るよりよっぽど安全な構成になっていると信じて、また実際に外れても大丈夫な設計にした上で、労力を新しい要素に向けていくのが良いのではないかと思う。
そしてお客さんベースで考えて、安くなるならプライベートクラウドよりもパブリッククラウドを使ってしまうなど、していけばいいと思う。
波田野
レガシー時代の話をさせてきた中で、我々はエンジニアの仕事をしてきたのか、ということが有ります。
エンジニアリングにより近い形で物を作れる環境になってきたと思っている。人は構造化しないとドキュメントをかけない。AWSのドキュメントを見るとそうで構造化されている。ドキュメンテーションもエンジニアリングの一つではないかと考えています。
エンジニアリングは生産工学から来た言葉で、サービス運用は外部からインバウンドがあって自分の中でキューでためてアウトバウンドで各部署とやりとりするという形になっている。では他部署とのエンドポイントをAPIのように疎結合にしていくことで生産効率をあげられるのではないか。
生産、品質、コストの３つを揃えて語れるようになってエンジニアリングといえるのではないでしょうか。
インターネットは安くて手間を掛けないというのが特徴で、運用設計とドキュメンテーションがないがしろにされてきた。それが設計された金型で大量生産するような従来出来なかった生産体制が可能になってきたのがChefなどではないかと思う。
脱属人化をするにはWhyが必要。ドキュメントというとたくさん書かなきゃいけないイメージがあるかもしれないですが、Whyを共有できればドキュメントはコードから引っ張ってきたシンプルなもので良くなるはずであると考えている。
荒木
クラウド時代の運用を担う人が使うべきツールをそれぞれ上げて頂けますか？
澤登
まず触って見るなら、Vagrantがいいです。今まで行ってきたことを感覚として体験するならVagrantが最適ではないかと思います。さっき行ったような環境を作って壊したりをするとお金がかかるが、Vagrantを使うとローカルでインフラ全体を作ってすぐに講話すということが可能になります。
波田野
AWSのCLIを生でAPI叩くということをするといい。APIというものを知らないとこれから大変だと思う。あとドキュメント。最大の運用ツールはドキュメントである。
今井
コードを書くことです。デヴェロッパとの間の関係も良くなるだろうし、インフラエンジニアが不足しているが会社が小さいとインフラ専門のエンジニアは取れない。RubyがかけてRailsができてサービスまでかけちゃうと、ぜひ来てください！という人材になると思います。
荒木
運用エンジアはこれからどんどん必要になるし、ツールもどんどん増えてきています。
AWSにアレがアレばいいと思うのがあればぜひ書いていってください。
AWSソリューションアーキテクトの仕事はドキュメントの内容を噛み砕いてご説明することだと思っているので、わかりにくい所があれば仰っていただきたいと思う。
最後に皆さん一言ずつメッセージを
澤登
まずは使ってみて評価してみてダメだったらやめちゃうのがいい
今井
日本語のドキュメントや、利用例が少ないので、みんなで試して結果を共有できればと思う
波田野
AWS-UG CLIというのを立ち上げました。
CLIはどky面とかしやすいという話をしています。FacebookのグループとDoorkeeperのイベントをどうぞ。