AWS Summit 2014 Tokyo「【パネルディスカッション】クラウド時代の運用」レポート

#レポート

#AWS

虎塚

2014.08.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

先月AWSサミットで行われたセッション「【パネルディスカッション】クラウド時代の運用」をタイムシフト聴講しましたので、レポートを書きます。

はじめに

パネルディスカッション参加者紹介

モデレーター: 荒木さん（アマゾンデータサービスジャパン）
パネリスト: 運用の世界の有識者
- 波田野裕一さん（運用設計ラボ合同会社）「レガシー運用」、セキュリティ方面に詳しい方
- 今井大介さん（株式会社ネットプライスドットコム）AWSでDevOpsを実現するCLIを作成して運用中
- 澤登亨彦さん（HiganWorks LLC、OpsRock LLC）アスキー・メディアワークス『Chef活用ガイド』の著者

波田野さんのお名前の漢字をレポート内で間違えていましたので、訂正いたしました。大変申し訳ございませんでした。

なぜこのパネルをやろうと思ったか（荒木さん）

2013年のnikkeiBPの調査によると、IT関連コストの45%が「運用コスト」、保守を含めれば75%が運用コストだった。つまり、運用のことを考えずにクラウドを、ひいてはITシステムを考えるのはおかしい！

運用の現場、状況

大きな現場での運用（波田野さん）

2009年夏から理想の「運用」を追い求めて旅に出た。理想の運用とは次のようなもの。

サービスが安定する運用
スタッフの業務負荷が平準的な運用
適正に評価される運用

現場でよくある声: 業務が多岐にわたりすべてを把握できない。ドキュメントが整備されていない。優秀な人が定着しない。がんばっても評価されている実感がない。開発者から「運用でカバーして」といわれる。（JPNIC　運用方法論より）

運用現場の悩みは共通。そして、その悩みや苦労が、自分たちの努力不足が原因だと思っている運用現場が多い。

そもそも「運用」とは、14世紀に中国で生まれた「活用」という意味の言葉だが、本来の言葉の意味で使われていない。運用費は「その他費用」扱いにされがち。はっきりしない内容の作業があると「じゃあそれ運用費でやろう」とばかりに予算を持っていかれ、本当にやるべき運用基盤を整備するための予算が残らないことも。

問題をまとめると、高負荷、属人的、見えない費用対効果（最初は有り難がられても、そのうちやって当たり前になり、費用は一定なのに効果が落ちていく）。運用現場は予算権限を持っていないことが多く、コストカットされやすい。その結果、やるべきことができない。

スタートアップでの運用（今井さん）

スタートアップの開発と運用をめぐる状況は、『リーンスタートアップ』の影響が大きく、小さく生み、変化し続けることを重視している。そこでは次のような背景と課題がある。

インフラ専門のエンジニアがいない少人数で立ち上げ → 運用が考慮されない
周期の短い開発で、ビジネスでの検証を優先 → プロダクトが変化し続ける（枯れない）
経験の浅い若手中心 → 属人的、経験依存

今井さんは、設計の部分と、開発から運用への引き継ぎの部分で、特に課題を感じている。事業が始まるとDevよりOpsの期間の方が長いという現実や、並列で複数のプロジェクトを回す状況を前に、十分に対応するのは大変。

その結果、担当者しか設定できない環境を作ってしまい、開発したエンジニア自体がボトルネックになる。開発者にとって手離れの悪い案件となるし、運用者にとってバッドノウハウを引きずる苦しみが続く。非効率、不正確な運用と積み重なる恨みは、もちろんシステムの品質低下をも招く。

効率を上げることに成功している現場での運用（澤登さん）

Infrastructure as Code: インフラの構成や管理をコードに記述して実行することで実現すること。

クラウドと構成管理ツールを組み合わせることで効率化され、運用も上手く回りはじめる。

APIでサーバ調達と構成管理ができる状態（例）サーバ台数を知りたいとき。従来のようにファイルサーバに格納した一覧表を見なくても、プロバイダにAPIで問い合わせることで現在の情報を動的に取得できる。一覧表に記述し忘れることを心配しなくてよい。

コードにすることで再現性が上がり、人による失敗が少ない同じ構成を別の環境にコピーしやすいので、テストや環境移行がしやすい

自動化は運用を救うのか？

自動化の歴史は長いが、これまで上手くいかなかった理由は何か。どうすれば運用を救う自動化ができるのか。

自動化の注意点（波田野さん）

最大の問題点は、自動化された結果だけが残っていて、自動化した理由が分からないこと。

自動化は客観化の先にある説
- 記録 → 整理 → 客観化 → 脱属人
- まず、メモとしての記録がある。次に、自分がやっていることを知る段階。そして、他者に自分の業務を説明する段階。最後に、安定化と永続化のために、時と空間を超えて知見を共有するために書く段階がある。

業務企画、業務設計の結果として、自動化にたどりつける。自動化を目的にすると、弊害として次のようなことが起きる。

自動化されたもの自体の保守が属人化する
自動化によって仕様がブラックボックス化し、業務プロセスが変更できなくなる
自動化された業務でトラブルが起きると、手動でリカバリするのがすごく難しい

自動化することを最初から目的にすると失敗しやすい。これを「手段と目的を間違えるな」という説教と同じだと単純化しないで欲しい。運用は大量に捌くための工場モデル、開発は手段を追求する研究所モデルが適切だと考えれば、運用では目的を重視した方がよいと理解してもらえるのではないか。

運用は「設計＋構成管理」から（澤登さん）

設計の前提条件を見直そう。たとえば、物理ベースのシステム信頼性判断から、コンポーネントの独立性と組み合わせによる耐障害性アップによる信頼性向上へ。多重構成重視から、1つ落ちても大丈夫な構成へ。今までと同じ方法ができないからダメ、と考えるのではなく、新しいやり方に対応を。

役割ベースでシステム構成を管理することで、上流から最適化しよう。

PaaS/SaaSの活用で運用の負担を減らす
オンプレミスをIaaSへ移行して構成の再現性と可搬性を上げる
「替えが利く」ことを活かす障害対応へ

Developerとツールやスキルを共有しよう: コードを書いて実行する点は同じ

インフラ要素のモデル化や、GitHubの利用、テストスイートの準備、各種ツールとのインテグレーションをしていく。そうすることで運用フェーズの課題も開発段階から見えやすい。ドキュメントだけを重視しなくてもよくなるのではないか。

Q: ドキュメントにまで手が回らない。きれいなコミットログが書けない。という場合は？（荒木さん）
A: GitHubならissue駆動で。issueに対応してコミットを紐づけていけばトレースしやすい（澤登さん）

どうやって正しい環境を作ったのか？（今井さん）

運用に渡せて、運用も困らない環境にするため、学ぶモデルとしてのインフラ構築を目指した。理想としては、

良いベース環境を用意する
- よく考えられた、「なぜそうなっているのか」の理由がある環境
- 環境による制約を課すことで、悪癖を防ぐ
ベストプラクティスをコードで残す: 読解しやすく、再現性がある
理解と実態の分離: 引き渡しの負荷を減らし、環境の理解が浅くても運用を回せるように

とはいえ、すべての運用担当がCloudFormationとOpsWorksを使って自動化環境を作れるかというとむずかしい。そこで、環境構築からすべてコマンド化するツールを作った。

horetコマンド: CloudFormationとOpsWorksのAPIラッパー。素早いプロトタイピングのためのシンプルなtemplateを、標準環境として作成できる。

実案件で使ったところ、途中から要件がどんどん追加されて、環境が変化していったが、コードとテンプレートの変更をGitHubで管理したところ、上手くいった。

クラウド時代の運用とエンジニアとは？

開発エンジニア、運用エンジニアを分ける時代ではなくなってきた今、運用エンジニアに求められる未来像とは？

開発から運用への引き渡しができること（今井さん）

先ほど紹介した自動ツールを使うには、OpsWorksやCloudFormationの仕組みを知らないと結局は困る。そういう状況になると、皆、他者が書いたレシピや自動化ツールのコードを読み始めるようになった。

良い方法は、「理解している人に構築してもらい、構築された環境からベストプラクティスを学ぶ」こと。運用しながら理解を深める。社内では、作ったテンプレートはすべてGitHubで管理し、それをベースに新しい構成を作れるような環境にした。

環境とコードによるベストプラクティスから学ぼうとする姿勢が人を育てる。また、放り込まれた運用の環境から学んで、構築も運用もできるようになり、さらに他の人に渡せるようになっていくことが大事。

既存の考え方をクラウドに合わせてアップデートすること（澤登さん）

既存ワークフローのこだわり要素を、クラウドに合わせてアップデートしていくことが大事。クラウドベンダー側が持っているインフラの耐障害性や復旧フローへのこだわりを信じて、新しい設計を取り入れていく。

エンドユーザを基準に考えることも大事。たとえば、自社プライベートクラウドより安くなるパブリッククラウドがあるなら採用するなど。

クラウド運用のキーワード「構造化」を実現すること（波田野さん）

ここでいう構造化とは、「エンジニアリングの実践」に近い意味。

物理設計に縛られていた考え方から、論理設計中心の考え方へ
- 失敗や試行がしやすくなった
- 環境に影響を与えずに構築を試すことができるようになった(dry-run)

問題を根性でなくエンジニアリングで解決したい。

サービス運用業務は、各部署がインバウンドとキューとアウトバウンドの機能を持ち、やり取りするようなもの。それぞれの部署にエンドポイントがあり、提携業務をAPIでつなげて、疎結合に活動するような運用エンジニアリングがあるかもしれない。重要なのは、「運用プロセスの構造化。データを使ってQCDで物事を説明するのが、クラウド時代のエンジニアリングだと思う。

これまではインターネット運用は、安く手間をかけないことを重視してきたので、ドキュメントを軽視しがちだが、これはエンジニアリングの世界では例外的だと認識して欲しい。今までは、生産ラインを最初に動かして、後から金型（設計とドキュメント）を作っていたようなもの。いわばアウトプットの定義が足りなかった。これからは先に金型を作ってから、生産ラインを動かす時代。

レシピやJSONはドキュメントの一部。コードでHowとWhatは表現できるが、脱属人化するにはWhyが重要。いずれドキュメントツールが進歩して、ソースにWhyを書き足せば、引き継げるくらい軽量化するようになるかも。

おわりに

クラウド時代の「運用」を担う人が使うべきツールとは？

（澤登さん）まず触ってみるならVagrant。VagrantとProvisioning機能で、今回話したような感覚を養おう。設計と構築を同時に行い、動作検証が取れたコードを投入しよう。

（波田野さん）AWS CLI。APIを理解するのが大事。AWSの公式ドキュメントが有用なので読もう。

（今井さん）コードを書くのがよいのでは。インフラオンリーのエンジニアは小さい会社では採用しづらいが、コードもインフラもできる人はスタートアップで採用しやすい。

（荒木さん）インフラエンジニアはこれからも必要だし、インフラエンジニアを支えるツールも増えている。AWSで欲しい新機能があれば伝えてください。

最後にひとこと

（澤登さん）まず触ってみて評価して、ダメならやめればいいので、やってみましょう
（今井さん）日本語ドキュメントや適用例が少ないので、皆で試して結果を共有しましょう
（波田野さん）JAWS-UG CLIを立ち上げたので、参加してください

以上です。

感想

ドキュメント重視派の波田野さんと、従来のドキュメントではない自己記述的な仕組みを重視する澤登さんのそれぞれのご意見が聴ける、面白いセッションでした。構造化されたドキュメントを推奨する波田野さんは、その論自体が構造化されていて、非常に分かりやすく、説得力がありました。また一方、澤登さんが推奨される現代的なツールも魅力的ですね。私はまだそれらに習熟する途上なので、これからもっと触って、良いところを仕事に取り入れていこうと思います。

# 荒木さんもおっしゃっていましたが、「Opsは大量生産工場型だから目的重視、Devは研究所型だから手段重視」という考え方は面白いと思いました。

今井さんのお話に出てきたCloiudFormationやChefの基本となるテンプレートを社内で共有・管理するというのは、クラスメソッドでもやっていることです。基本のテンプレートから、ちょっと変えた構成が必要なときに作ったテンプレートを、どういうふうに管理していけば、次も使える資産になるかについて、良い方法があればぜひ知りたいと思いました。たとえば、基本のテンプレートに加えた更新を、ちょっと構成を変えたテンプレートにも適用したいときとしたくないときがあったとして、それをどう管理すればよいのかなど。

スライドの最後に出てきたAWSの運用チェックリスト（http://aws.amazon.com/whitepapers/operational-checklists-for-aws/）は、このレポートを書いた時点では英語版だけの提供ですが、植木さんが記事を書いていますので、概要を掴みたい方はそちらをご覧ください。