インフラ構築と運用の自動化ツール「Ansible」は世界中で活用され、日本国内でも多くの活用事例が見られるようになりました。レッドハットでは従来の手作業をシステムに置き換える自動化を「自動化1.0」と定義し、今後はこれを発展させ、インフラ構築と運用作業の90%以上を占める人や組織のオーバーヘッドを削減する自動化を「自動化2.0」と定義し推進しています。
「自動化2.0とは何か」から、Ansibleの活用事例を紹介、レッドハットのプロフェッショナルと対話・質問まで、ITインフラの自動化で大きな効果を出すための情報を一挙に知ることができる「Red Hat Ansible Automates 2021 Japan」が7月13日、20日の2日間に渡りオンラインで開催されました。本記事では、このイベントのセッションについて紹介します。
イベントページではイベントで投影された資料や動画などが公開されています。ITインフラ自動化や自動化2.0に興味のある方は以下のサイトから閲覧してみてください。
Red Hat Ansible Automates資料・動画まとめページへ
目次
Day1 基調講演：自動化推進を「自動化」する秘訣が明らかに
株式会社NTTドコモ 飯田 和則 氏
全作業の30%を自動化し、コスト削減にも成功
Day1の基調講演「自動化推進を”自動化”する 〜自動化の自走力をいかにつけるか〜」は、自動化推進を「自動化」するための自走するチームの作り方をテーマに行われました。飯田氏は、NTTドコモでISPサービスのインフラ開発維持を担当しています。本セッションで取り上げる自動化の適用システムは、ドコモのSPモード・iモード等のISPサービスです。
飯田氏は、NTTドコモの2020昨年度末での自動化実績を示しました。NTTドコモでは作業上で必要なPlaybook等の準備状況を自動化部品率と呼んでいます。すでに98％が準備され、全ての作業の30%が自動化されているそうです。
その結果、2020年度はインフラ工事で34％程度のコスト削減に成功しています。製品の事前検証については、仮想基盤でOpenStackを使ってCI化を進めることで、評価期間を80％、評価工数を90％削減する実績があげられたといいます。
ネガティブ反応に苦戦も理由を究明し解決
しかし、当初は飯田氏が旗を振っても思うようには自動化は進まなかったといいます。いくつかの取り組みの中でわかったことはテクノロジーがネックとなって自動化推進が進まないのではなく、人の「心」「感情」がネックになっており「腹落ち」がなかったからだと飯田氏は分析。その対応策を講演の中で明らかにしていきました。
自動化の初期段階では効果を目的とせずに、自動化そのものを目的化した。そのために「まずはやってみる」ことを主眼に自動化専任者を組織化したCoE（Center of Excellence）体制を構築。CoEが小さなトライアンドエラーを繰り返すことで、徐々に自動化への取り組みが波及し、それが大きな流れを作り、「現場がどんどん進めてくれている」自動化推進が自走し始めたと飯田氏はいいます。
自動化2.0の世界観を取り入れる
2020年度実績で30％だった自動化の適用率を、倍の60％に引き上げることが2021年の取り組みの1つだそうです。作ったPlaybook等の資産を連結することで小さな作業から大きなものへ連結しボタン化することで、セルフサービス化を進めインフラ開発を自動化することを目指しています。
このコンセプトは、Red Hat が提唱する自動化2.0の世界観そのもので、NTTドコモは自動化2.0の世界を実現する先駆者として取り組みを進めたいと飯田氏は話しました。これまではあえて自動化を目的化して推進してきましたが、2021年度からは自動化を手段へと移行していくのだといいます。
最後に、自動化推進の成功の鍵はテクノロジーではなく、自走する人・組織の整備による「推進の自動化」にあると飯田氏はまとめました。
講演後のQ&Aでは、どのようなプロセスに自動化を適用したか、自社システムは特殊だから自動化が難しいという社内からの声にどう対応すべきかといった問いに飯田氏は、体制をいかに作るかが重要だと話しました。
Day2 基調講演：自動化1.0から2.0へと歩みを進める方法とは？
レッドハット株式会社 中島 倫明 氏
レッドハット株式会社 佐藤 暁 氏
Day2の基調講演「これからのインフラ自動化 〜自動化1.0から2.0へ、その進め方〜」は前半・後半の二部構成で自動化2.0の意味・意義と進め方をメインテーマに展開されました。前半は中島氏が自動化1.0から自動化2.0へと歩を進めている背景を解説し、後半は中島氏と佐藤氏が自動化2.0の進め方について対談形式でポイントを紹介します。
はじめに中島氏は、何を自動化するか？ではなく「どんな課題を解決するのか？」という視点で自動化を捉えるとより理解が深まると話しました。
自動化1.0、自動化2.0とは何か？
ITインフラの自動化に期待される効果について図を使った解説がありました。上の図では調整・準備（50.0%）、実作業50.0%のうち、実作業の半分を自動化すると全体に対して25%の効率化があるということになります。全体の4分の1を削減できれば自動化の効果は非常に高く、このような効果が期待されていると中島氏は話しました。
しかし、現実を見ると多くの企業において調整・準備は90.0%に近く、実作業は10.0%ほどになっており、企業によっては比率が95:5、99:1にも達している場合もある。この状態で実作業だけに注目し、実作業の半分にしても大きな効果にはつながりません。調整・準備の比率が増えるほど、実作業にフォーカスした自動化は効果を発揮しづらくなっているのです。工数の大半が人のやり取りやドキュメントの作成・レビュー、打ち合わせなどコミュニケーションに費やされているという現実を正しく認識する必要があります。
ここまでの話でいうと実作業の課題にフォーカスしてツールやスクリプトに置き換えて自動化していくのが自動化1.0です。
自動化2.0とは、インフラ作業全般を見たときに支配的な要素である上の図の赤い部分、つまり調整・準備といった人と人がコミュニケーションをとって作業の品質をあげる過程に自動化を作用させて全体の効率化に繋げていくものだと中島氏はいいます。
コミュニケーションにフォーカスする自動化2.0
調整・準備部分を自動化するポイントは3つあります。Ansibleによる自動化2.0へのアプローチとして示されたのは作業の登場人物を減らす「自動化のサービス化」、人とシステムの対話で品質を上げる「インフラCI化」、自動化1.0の開発効率を上げて自動化2.0への移行を促進する「自動化の標準化」です。
システムが大規模化、複雑化してインフラ作業の構成比率が変化したことで、自動化1.0から自動化2.0にシフトすることが重要になっています。これは手順からコミュニケーションに着目した自動化であり、これを強力にサポートするのがAnsibleだと中島氏は話しました。自動化2.0を推進する上でAnsibleはとても有益なツールです。
自動化2.0の普及は「これから」
ここで佐藤氏が加わり、中島氏との対談形式で自動化2.0を実現する進め方に焦点が当てられていきました。
日本で自動化1.0、自動化2.0が取り組まれているレベルについて、佐藤氏は最近ではAnsibleやIaC（Infrastructure as Code）といったキーワードの説明が必要な場面が減り、自動化に着手しているケースも多く見られると話します。Ansibleによる自動化1.0は当たり前になりつつあるといえるそうです。
その一方、ワークショップで見た自動化の取り組み状況を集計した事例では自動化1.0に着手していても自動化2.0についてはまだまだというのが実情だといいます。インフラCIや継続的なサービス化が進められているケースは稀です。
中島氏はなぜ自動化2.0への取り組みが少ないのか佐藤氏に問いました。自動化1.0に取り組んでいく中で、その延長線上で大きな効果を求めていくと自然と自動化2.0へシフトするのではないかといった疑問です。
これに佐藤氏は目の前の作業を自動化に終止することが多いからだと答えます。日本では組織の構成上、業務が縦割りになりやすいため一部の業務にフォーカスした自動化から手をつけがちです。このような部分最適では、逆に調整・準備が増えたり、効率が悪くなったり、コストが上がったりすると佐藤氏は指摘します。また、全体最適化を目指すゴール設定がされていても、ゴールと計画のギャップが大きすぎて自動化2.0に進めないことも多いようです。
中島氏は、これを受けて自動化1.0から自動化2.0へシフトしていくには従来の延長線上にある取り組みだけでは超えがたいギャップがあるとまとめました。
自動化2.0へ進む上で重要なポイント
佐藤氏は自動化2.0へと進むにあたり、押さえておくべき重要なポイントがいくつかあると話しました。自動化対象の選定にはコミュニケーションコストなどに注目するトップダウンの考え方で、短いサイクルで状況の変化に対応しつつ、小さくとも確実な成果を出していくアジャイル開発の考え方と進め方を適用することが重要です。
自動化1.0への取り組みの課題を再認識して、足りない要素を補完して自動化2.0へと進むと着実かつ継続的な成果を出していくことが可能だと佐藤氏はいいます。
「壮大な計画」があると自動化2.0は進みにくいようです。大きすぎるゴールに長いサイクルで向かう進め方が経験的に上手くいかないことがわかっており、この課題を改善する試みがアジャイル開発の考え方や手法です。
インフラの世界も昔はハードウェアを軸にした作業が中心でしたが、今はソフトウェア化が進んだことによりサービスとして提供することが最重要になっているため、アジャイル開発の考え方などを活用することが必須になっているのです。
上のスライドの左側はVM（仮想マシン）申請から払い出しまでのセルフサービス化を目指し、短い周期でそれぞれのゴールに向かい、フィードバックによる微調整を加えながら開発を進めていく例です。右側は最初に緻密かつ長期の計画を立てて計画を遵守して進めていく例です。
この右側の例のように最初に立てた計画通り進めて数年後に目標とは大きなギャップが生まれて失敗するよりも、この左側の例のように短いサイクルで現実的なゴールへと向かい、仮に失敗するとしても早めに失敗してすぐに軌道修正できるようにした方が良いことは誰でも容易に想定できると佐藤氏は話しました。
ここで中島氏は佐藤氏に自動化2.0へと進む最重要ポイントは何かと聞きました。佐藤氏は、短いサイクルの中で実現可能な小さなゴール設定と確実な成果を出す成功体験を積み重ねていくことが最も重要だと答えました。
自動化2.0の進め方では各バージョンに最小限の機能セットがあるMVP（Minimum Viable Product）しかありませんが、価値を提供できるためフィードバックが得られて軌道修正も可能です。
中島氏は小さくてもきちんと動くサービスを作り、ユーザーの反応を見ながら軌道修正して開発を進めることが重要だとまとめました。
自動化2.0の技術要素、キーワード
ここで自動化2.0に必要な要素が表示されました。品質を確保しつつ自動化2.0を進めるためのインフラCI、自動化実装を短いサイクルで行うアジャイル開発、各タスクの達成の定義を明確にするためのDoD（Definition of Done）、Gitのイベントでプロセスを進めるGitOps、インフラ業務手順を高度化するIaCといった様々な要素が必要になります。自動化2.0を進める上でこれら要素の考え方や手法取り入れて進めることは非常に有効だと佐藤氏は指摘しました。
中島氏はこれらの要素はこれまでのインフラではほとんど触れる機会がなかったものだと話します。これらを活用したインフラ業務の進め方について知る機会はあるかと佐藤氏に尋ねました。佐藤氏は「Red Hat Ansible Automates 2021 Japan」などがそれにあたると話し、小さくても確実で重要な自動化2.0の次の一歩を踏み出してほしいとまとめました。
Red Hat Ansible Automates資料・動画まとめページへ
自動化2.0をはじめるには、まずこのポイントから押さえるのが“勘所”
レッドハット株式会社 吉丸 新一郎 氏
レッドハット株式会社 佐藤 暁 氏
セッション「自動化2.0のはじめかた、教えます」は、自動化2.0を進めるにあたって「何からはじめたら良いのか？」という疑問に答え、自動化が上手く進まない悩みに答えるのがテーマです。
はじめに吉丸氏は、なぜ自動化2.0の「はじめかた」の話をするのかという点について、支援実績に基づいた進め方の事例の話をして、自動化2.0を実現するために重要なのはAnsibleだけではないこと、最初期につまずきやすいポイントを共有したいからだと話しました。
Ansibleを使ったことがない場合は
吉丸氏はAnsibleを使ったことがない場合は、このセッションも参考にしつつオンラインではじめられる無料教材を活用するのが良いと話しました。
- Ansibleトレイルマップ（初級編は環境不要）
- Ansibleワークショップ（要環境）
1.小さく、1人ではじめる
吉丸氏は「個人（自分）」からはじめるのがポイントだといいます。小さくやってみて、短い期間で効果を実感できる最小限のもの、つまり「MVP」をまず作り、成功体験を味わうことが大切です。Ansibleの場合、MVPはPlaybookということになります。
目標が先にあっても、小さくステップを踏み、軌道修正をしながら最終的に到達したい望まれるゴールに進んでいくのがポイントです。
2.チームではじめて自動化1.0から自動化2.0へ
1人でできたら、小さなチームを作って小さくやってみるのがわかりやすいと吉丸氏は話します。チームで成功体験を得るのが目的です。チームになると「チーム結成」「目的共有」というステップが生まれます。メンバー全員が同じ目的に同意することが重要なポイントになります。
そして、これが実際の支援でも難しいポイントだと吉丸氏は指摘しました。なぜかというと仮にチームとして招集されてもメンバーがそれぞれ別々の目的を持って自分の自動化だけをやると、いくら進んでも自動化1.0から抜け出せないからです。
吉丸氏はチームで進めるため「チーム組成Tips」「業務分析Tips」「チーム開発Tips」といったTipsを示しました。VSM（Value Stream Map）なども活用してチームで羅針盤を持つことが重要です。また、VCS（Version Control System）などアジャイル開発の手法を活用することもポイントになってきます。
3.大きく育てる
チームでできたら組織で進めるステップに移ります。推進組織を作って活動をリードしていくことになります。急にハードルが上がるイメージがあっても、やることは基本的に変わらないと吉丸氏は話しました。
より深く理解するための書籍紹介など
吉丸氏は、自動化2.0や関連キーワードをより深く理解するための書籍を3冊紹介しました。そして自動化2.0をはじめるための勘所を3点にまとめました。
- 目標は大きくても、取り組みは小さくはじめて徐々に育てる
- 自分の業務を自動化する視点から、周辺の業務を巻き込む自動化の視点へ
- （何よりも）素晴らしいことを実現したいと願う強い意志
レッドハットでも支援サービスを展開しています。この後、佐藤氏が加わって視聴者からの質問に答える展開となりました。
Ansibleのトラブル対策のポイント
レッドハット株式会社 杉村 貴士 氏
レッドハット株式会社 八木澤 健人 氏
セッション「Ansibleトラブルシュート 傾向と対策」では、Ansibleのトラブル対策のポイントが紹介されました。
八木澤氏はトラブルシューティングではAnsibleに限らずITシステム・ソフトウェアでも基本は同じステップを踏むと前置きして、サポートエンジニアは状況把握からスタートして仮説、検証、考察のステップを回し原因を絞り込んでいくと話します。杉村氏は実際に手を動かして検証するのがとても大事であると付け加えました。
Ansibleを利用している上で起きる問題は多種多様なため、必要に応じてVerbosity（-v）を増やしてより詳細な出力を取得して状況を把握するなどしています。検証の際はコードをチェックしたりGitHubのIssueも確認したりすることも大切です。
エラーが出るとそこにだけに目が向きがちですが、実際には問題のないエラー、ワーニングもあり、全てを検証するのは難しいため、正常な状態を定義しておいてサービスが提供できているかを確認するのがポイントになります。
サポートに届く問い合わせで圧倒的に多いのは、接続に関する問題だと八木澤氏は話します。設定ミスや外的要因など、考えられる原因が多いため、トラブルシュートが難しい問題です。SSHのジャンプホストが使われているケースも多く、具体的にどこがダメかといった絞り込みに苦労するケースやKerberos認証等、Ansible以外の知識が必要になることも多く発生しているといいます。
最後に八木澤氏、杉村氏はAnsibleの問題を解決するためにサポートを活用してほしいとまとめました。
多種なセッションが展開された「Red Hat Ansible Automates 2021 Japan」
「Red Hat Ansible Automates 2021 Japan」は、Day1、Day2に渡り、様々な企業でのAnsible活用事例や自動化導入によって開発業務がどう変化したかといったレポート、開発手法や制御テクニックの紹介など多様なセッションが展開されました。
Day2の基調講演「これからのインフラ自動化 〜自動化1.0から2.0へ、その進め方〜」で示された「自動化2.0に必要な要素の例」などを参考にして、興味を持ったキーワードをタイトルに含むセッションから視聴していくのも有益かもしれません。
- Red Hat Ansible Automates 2021 Japan
Red Hat Ansible Automates資料・動画まとめページへ
また、自動化を進めるにあたり、Ansibleについて知りたい方向けの無償の学習コンテンツが揃っています。Ansibleをこれから学ぶ方向けの「Ansibleマンガ」や、オンライン教材「Ansibleトレイルマップ」が用意されています。これらはすべて無料提供されているそうです。興味のある方はぜひご覧ください。
Ansibleをこれから学ぶあなたに : Ansibleマンガ
Ansibleを最短距離で学ぶ : Ansibleトレイルマップ -Mt.Yaml-
自動化2.0で“本当に解決したい課題” へアプローチ: Ansibleトレイルマップ -Mt.Button-
編集後記
基調講演で、飯田氏が自動化推進を阻むのは人の「心」「感情」であるとの指摘がとても興味深いと感じました。凝り固まった人の心を解きほぐすのは小さな成功体験の積み重ねにあり、それをくり返した先に自動化2.0の素晴らしい世界が広がっているのです。
そのために我々がまず何をしていけば良いのか？ 小さなステップの重要性をはじめ多くの気づきが得られたイベントでした。
取材／文：神田 富士晴