ITインフラ自動化のあらゆるトピック・事例が紹介された、Red Hat Ansible Automates Tokyo 2020 Day1

2020年7月30日

Ansibleは、リリースから8年が経過し、当初から志向されているモジュラーな考え方により提供モジュールは3,000以上を超え、世界中多岐に渡る分野で活用されるようになりました。

そんなAnsibleの活用事例やレッドハットのプロフェッショナルへ質問ができる「Ansible Automates Tokyo 2020」が6月16日、6月23日の2日間に渡ってオンラインで開催されました。また、登録者が多く、好評につき7月7日のDay3も追加されました。

この記事では、同イベントのセッションについてまとめています。
また、イベント後早々にスライドや動画がアップされました。ITインフラ自動化にご興味のある方は以下のサイトから閲覧してみてはいかがでしょうか。

Red Hat Ansible Automates資料・動画まとめページへ

自動化を進めるための虎の巻伝授！～ITインフラ自動化を進める自動化2.0とAutomation Adopotion Program～

レッドハット株式会社　中島倫明氏

本セッションでは、自動化2.0が、ITインフラの自動化を進めていく上で重要な概念であることが紹介されました。

セッションで特にわかりやすかったのは、以下の図です。以下のスライドでは、自動化1.0と自動化2.0の違いを工場の変化になぞらえて説明されました。自動化1.0は人が作業し機械が補助をする状態を、自動化2.0は機械が作業し機械が管理する状態を、それぞれ指しています。自動化1.0から2.0になることで手動前提のインフラ構築の手法と組織をアップデートし、自動化の本来あるべき状態になることできます。

本セッションの動画はこちら

「折角Ansibleを導入しても、自動化のゴールを自動化1.0においているのか自動化2.0においているのかで自動化が進むか否かに差が出てしまう」と中島氏は強調します。
そこで、レッドハットでは自動化2.0へ向かうための取り組みを成功させたクライアントの歩みをAutomation Adopotion Journeyと呼び、Automation Adopotion Journey を歩むためのプログラムとして、Automation Adopotion Programを提供しています。

このセッションでは、「自動化2.0とは何か」の他に、「Automation Adopotion Programを用いて自動化を進めるためのポイント」、「自動化を進めるための流れを作り周りを巻き込むための仕組みづくり」、「成果を認知させ自動化を広げる仕組みづくり」が紹介されました。

中島氏はAutomation Adopotion Programを用いて自動化を進めるためのポイントとして、「専任をつけて自動化を推進していくこと」、「自動化2.0に至るステップとテーマを明確化すること」、「アジャイル的なアプローチを行い小さなサービス開発を積み上げていくこと」の3つを挙げました。自動化を進める最初のステップに有効な学習コンテンツとして、同日にリリースされたAnsible トレイルマップも紹介しました。

Ansibleトレイルマップ

運用自動化を支えるSmartCSの役割＆ユーザ事例紹介

セイコーソリューションズ株式会社　中山真一氏
ネットワンシステムズ株式会社　井上碧氏

セイコーソリューションズ株式会社が提供する国産のコンソールサーバーSmartCSは、Ansibleだけでは実現出来ないコンソールアクセスパーツを提供し、自動化が実現可能な対象の範囲を拡大することができます。

コンソールサーバーは、コンソールポートを集約し遠隔からコンソールアクセスを行うための装置です。導入することによって現地までいかずにオペレーションが可能になり、運用負荷の軽減が出来ます。

本セッションでは、SmartCSとAnsibleとの連携方法や連携のメリット、ユーザー事例についてご紹介されました。

SmartCSとAnsibleとの連携のメリットとして「IP到達性のないターゲットへのアクセスが可能になる」、「ライフラインを確保し、遠隔から敬遠しがちなオペレーションも自動化対象になる」、「Ansibleモジュールのないターゲットも管理対象になる」の3点を挙げ、Ansibleをよりパワフルに使うことが出来ると説明されました。

SmartCSとAnsibleとの連携は、SmartCS独自のモジュール「smartcs_tty_command」の利用もしくはベンダーモジュールとの連携で行えます。このセッションでは、それぞれのメリットや注意点についても言及されました。

事例紹介では、「検証環境の自動化」「大規模キッティングの自動化」「管理面（MNGポート）の冗長化」の3つのケースについて、やりたいこと、解決策、実現できたことをご紹介いただきました。

続いて、AnsibleとSmartCSを用いたネットワーク機器のキッティングの自動化事例について掘り下げた内容を、ネットワンシステムズの井上氏からご紹介がありました。

ネットワーク機器のキッティングとは、新規システムの導入や機器のリプレイス等の際にハードウェアやOSの設定を予め行うことにより、機器使用者による面倒な設定作業が不要となり、機器が到着したらすぐに利用できるというメリットがあります。

しかし、ネットワーク機器のキッティングを手動設定する際に、キッティングしたい機器が複数台ある場合には、機器の数だけ同じ作業を繰り返す必要があり、定型作業に時間が取られてしまいます。

「作業を自動化しようという」ことになってもまだ課題があります。
Ansibleを用いたネットワーク機器へのコンフィグ設定にはSSHが必要ですが、SSH接続を行うにはマネジメント用のIP設定が必要となり、マネジメント用の設定はキッティング専用に使用するため設定後に削除が必要になるというものです。

この課題を解決したのが、コンソールサーバーのAnsible対応です。
コンソールサーバーにはSSHの接続をしてAnsibleから操作を行い、コンソールサーバーに接続されているネットワーク機器は、コンソール接続経由でansible.comに管理されているモジュールを使用できます。

キッティングの自動化について、デモンストレーションでのご紹介がありました。

本セッションの動画はこちら

自動化を行ったことによる環境の変化として、時間的拘束が緩和され、設定ミスや設定者の精神的苦痛が改善されたとのことです。
また、設定投入中の時間を追加機器の準備やミーティングなど他の業務に充てるなど時間を有効活用できるようになったとも話しています。

環境だけでなく文化にも変化があったとのことです。

もともとAnsibleをほとんど知らないというような部署での自動化プロジェクトでしたが、プロジェクトを進めていくにつれてメンバーがAnsibleユーザー会で開催されているもくもく会に参加したり、自分でPlaybookを書いてみるようになったりと、自動化に対する考え方への変化を感じたと井上氏は説明しました。

最後に、中山氏から「SmartCSを従来のネットワーク運用だけでなく、運用自動化においても安心・安全を提供出来る装置にしていくための活動を続けていく」とセッションを締めくくりました。

「カオスエンジニアリング」をベアメタルで始めよう！

日本ヒューレット・パッカード株式会社　片山嘉彦氏 / 木村拓氏

システムの堅牢性を高めるための手法に「カオスエンジニアリング」があります。

「カオスエンジニアリング」は、アンチフラジャイルという考えに基づき、障害に対処すればするほど障害に強いシステムに出来るというもので、『信頼性のあるシステムの構築』を目的としています。
クラウドサービスは、OSSのカオスエンジニアリングツールを利用してシステムを壊して復旧するまでを自動化することが可能ですが、本セッションではベアメタル環境でもそれを実現しようということをデモンストレーションも交えて紹介されました。

本セッションの動画はこちら

システムの近代化に伴って、ダウンしないシステムを作ることから、ダウンしても自動回復可能なシステムを作っていくという考え方にシフトしました。それにより、障害の質にも変化が生じ、原因がどこにあるのか突き止めにくくなっています。
障害を早期に発見し、被害を最小限に抑える取り組みの1つとして、片山氏はカオスエンジニアリングを挙げています。

片山氏は、「実験の綿密な計画とコントロール」「障害に直面した際のシステムの動作実証」が、カオスエンジニアリングの遂行に必要だと言います。
カオスエンジニアリングは、本番環境で実施することに意味がありますが、事前の告知なしに障害を起こすわけにもいかないため、スケジューリングやチーム間での調整が必要です。
また、1回だけでなく何度も検証することも必要になるため、同じ障害を再現できること（冪等性の確保）が大切です。

「チーム間での調整がカオスエンジニアリングの遂行に必要」と記載しましたが、チームごとにテスト項目を持っているはずです。
例えば、サーバー運用チームはCPUへの負荷やサーバーの電源オフ、アプリ運用チームはパフォーマンステストや特定アプリのサービスダウン…などが挙げられるかと思います。

各チームがそれぞれのテスト項目を個別にPlaybook化し、自動化ボタンへの置換を行うことが第1ステップです。作成された複数のPlaybookを繋げあわせることで、障害シナリオの作成が可能になります。
これは、実作業の自動化、つまり自動化1.0に該当します。

第2ステップとして、自動化2.0の概念にあるように、チーム間での調整など作業前のプロセスも改善していきます。つまり、自動化ボタンをサービス化し、権限を付与して別のチームにも使える状態にすることで、必要最低限のチームでテストが行えるようになるということです。カオスエンジニアリングを実施する際の調整を自動化2.0の考え方で減らすことが可能です。