Tech Sketch Bucket of Technical Chips by TIS Inc.

Ansibleに代表される自動化/構成管理をホンネで語る (クラウド時代のOSS活用最前線) 〜 オープンソースカンファレンス 2016 Nagoyaでの2団体ジョイント企画 実施レポート

Pocket

さる5月28日(土曜),オープンソースカンファレンス2016 Nagoya が開催されました。私たちが加盟する,OSSコンソーシアムと,オープンソースビジネス推進協議会(OBCI)は,2団体の合同企画としてセミナとパネルディスカッションを実施しました。テーマは「Ansibleに代表される自動化/構成管理,ホンネで語る自動化/構成管理」です。

Logo-OSScons+OBCI-720w

オープンソースカンファレンス(OSC)の名古屋での会場は,今年は桜通線吹上駅近くの名古屋中小企業振興会館 で開催されることになりました。名古屋駅からはちょっとだけ離れましたが地下鉄1本で行けますし,展示会場がとても広くなり,出展側は後ろのブースとぶつからず,見学側もゆったりと見て回れるようになりました。

[Part 1] セミナ - Ansibleに代表される自動化/構成管理

20160528_OSC2016Nagoya_(2)セミナー-全景

まずは,Ansibleに代表されるITインフラ構築の自動化/構成管理に関する現状について,OSSコンソーシアム代表と,OBCI代表によるセミナです。

『Ansibleから始めるAutomation』 (OSSコンソーシアム クラウド部会/TIS 倉持健史)

20160528_OSC2016Nagoya_(3)セミナー-TIS倉持

ITインフラの構築・運用の構成と手順を“記述”することは,“Infrastructure as Code”と言われるように,コードを書かないといけません。コードで記述しなさいと言うと,「それはそれでしんどい」と思ってしまう方もいるようです。しかし,なぜ自動化ツールが注目されてるかと言えば,それは「楽をするため」です。構築・運用作業そのもので楽をして,その時間を新しいことに振り向けることによって,ITエンジニアの活動範囲を広げたり,技術力の底上げにつなげたりすることが重要です。

構成管理と自動化を実現するツールはいくつか存在します。その中で,今もっとも注目されているのが Ansibleでしょう。このセミナーの直前にAnsible 2.1がリリースされました。Windows対応が強化されるなど,これまで以上に広く適用できるようになったとのことです。

ちょっと余談ですが,Ansibleの読み方は“えぁぁんしぼぉ”というように発音しないと英語をネイティブにする方たちには通じないよという話も披露されました。でも日本人同士だったら,やっぱり“あんしぶる”の方がわかりやすそうですね。

『マイクロソフトとレッドハットの連携と,Linuxとクラウド環境での自動化』 (日本マイクロソフト 新井真一郎氏,レッドハット 藤田稜氏)

20160528_OSC2016Nagoya_(4)セミナー-MS新井氏 20160528_OSC2016Nagoya_(5)セミナー-RH藤田氏

テーマである自動化/構成管理の前に,IT業界のビッグニュースであるマイクロソフトとレッドハットの連携について触れておきます。この2社がOSSを推し進める共通の立場で一緒に登壇する姿は想像できていませんでした。どちらが大きな変革をしたのかはご存知のとおりです。かつて「Linuxは癌だ」と言っていたマイクロソフトが「オープンソースに向かって全力で舵を切った」わけです。こういう大変革ができるというところがいちばんの驚きです。

マイクロソフトのクラウドサービスであるAzureでの自動化の現状ですが,AnsibleがAzureにも対応できるようになっているだけではなく,多数のOSSが数分間でデプロイできるように環境が整備されています。ちょっと意外なのは,OSもWindows系のものばかりではなくて,Linux環境がかなりの割合を占めており,中でもRed Hat Enterprise Linux (RHEL ←“レル”と読みます)を実行可能な『世界最大のクラウド環境』になっているとのことです。

発表者が交代して,レッドハットからもマイクロソフトとの連携の説明がありました。実は,レッドハットが名古屋でセミナーを行う機会はこれまでにあまり無かったそうで,今回「生身のレッドハットの人間を初めて見た」という方も多かったようです。

RHELはご存知のとおり,エンタープライズITで利用されるLinuxとして圧倒的なシェアを占めています。クラウド環境でLinuxを使う場合にも,RHELが第一候補になるケースが多いはずです。しかし,RHELは有償でサポート込みのサブスクリプションが提供されるもので,そのコストが課題になります。ここに,Azure(マイクロソフト)とレッドハットが連携している価値があり,Azure上では1時間で6円程度の価格でRHELを使えるそうです。開発やテストフェーズではとても助かります。

さて,Azure上でRHELや各種OSS環境を利用するときには“数分間でデプロイ可能だ”と書きました。それだけでも作業効率はたいへんに上がるわけですが,これがゴールではありません。「ボタンを押さないといけないのは本当の自動化ではない」わけです。状況を自動的に判断して,必要な措置を自動的に実行してくれるようになるのが,自動化が目指すべきゴールです。

[Part 2] パネルディスカッション - ホンネで語る自動化/構成管理

Part 1のセミナーの登壇者3名にメンバを追加して,セミナ形式では語りにくいことを語るパネルディスカッションです。 今回の登壇者は次のメンバです。

【パネラ(席順)】
* 日立ソリューションズ 吉田 行男 氏
* 日本マイクロソフト 新井 真一郎 氏
* レッドハット 藤田 稜 氏
* TIS 倉持 健史
【モデレータ】
* TIS 溝口 則行

20160528_OSC2016Nagoya_(6)パネルディスカッション

このパネルディスカッションで議論したい観点を,各パネラに事前に次のようにお願いしていました。

  • インフラ構築(や運用)の自動化,“Infrastructure as Code”が良いことばかりなワケがないし,誰でもすぐできるワケでもない。課題と現実をさらけ出して,メリットを享受するためのヒントとしたい。
  • また,運良くこれが進展した将来のITインフラ構築はどうなるのかにも触れたい。

正直に書くと,“ホンネで語る”と銘打ったパネルディスカッションの内容を記事として記すのは難しいです。その場の雰囲気や,メンバや来場者との掛け合いの中から出てきた自由な見解だからです。ですから,ここに記すのはポイントを絞ったものだけになる点をご了承ください。

自動化/構成管理の現状と課題

  • “Infrastructure as Code”という言葉が示すようにコードを書かないといけないが,インフラ屋にコードを書かせるのはたいへんではないか?
  • 従来のインフラエンジニアは不要になるか,もっと言えば,邪魔者になるのではないか?

この課題意識に対して,各パネラから次のような意見が述べられました。

  • システムインテグレータの現場では,導入手順書とかパラメータシートなどの文書化に手間を掛け,さらに作業時にはダブルチェック,トリプルチェックと多くの工数を費やしている。自動化技術の活用がこれらの工数削減に寄与することを期待できる。しかし反面,いわゆるインフラエンジニア達に,これまでやってこなかった自動化のためのコード作成を身につけさせるのは簡単でないという現実もある。

  • “Infrastructure as Code”は好むと好まざると進展し普及していく。結果としてそれができるところに仕事が流れていくだけのこと。「難しい」,「できない」と言っていたら仕事が無くなっていくだけ。

  • すでに現時点でも,サービス提供部隊(ユーザ部門であることもある)が,インフラ構築部隊に頼ることをやめて,自分たちで自動化を推進している。「インフラ構築部隊に頼むと遅い」というのが理由。それが“DevOps”の実体。

  • コードを書かないといけないといっても,C言語などのプログラミングをするのよりは,ずっと簡単なものだ。難しくはない。

  • 他のメンバが作った自動化コードを引き取ってその後のサポートをしているが,中身を見ればわかる。

20160528_OSC2016Nagoya_(7)パネル-吉田氏

つまり,簡単にまとめると次のような意見になります。

(1)効率化に期待する反面,新しい技術を身につけさせる苦労はある。

(2)生き残りのためには取り組まざるを得ない。インフラエンジニアの身の振り方の問題になってくる。

(3)サービス開発者たち(つまりコードを書くことに抵抗のない者たち)から実戦を始めている。

(4)コードと言っても難しいものでは無いはずだし,実際にわかりやすい(Ansibleの例)。

2団体合同企画を終えて

OSSコンソーシアムとOBCIの合同企画をOSCの場で行うのはこれが2回目になります。2枠連続の合同企画にしたのは,OSSに思いのある方たちが集まるこのオープンソースカンファレンスの場で「パネルディスカッションをやりたい」と考えたからです。セミナ形式ですと,どうしても“表向きの発言”になりがちですが,パネラ同士や会場からの発言による掛け合いによって,公式見解だけではない本音が引き出せれば,私たちOSS関連団体に関わる者にも,来場いただいた方たちにも,刺激ある/価値あるメッセージを持ち帰ってもらえるのではないかと考えたからです。 このねらいは,ある程度は実現できたと思います。クラウド環境やプロダクトを提供する立場からは,当然ながら,一歩先を見た提言が出てきます。システム構築を現場で担う立場からは期待感はもちろん持っていますが,変革する辛さもにじみ出てきます。 会場からは,「TISさんでは実際のところどれくらいの案件で自動化の採用が進んでいるんですか?」と,的を突いたというか,「そりゃあそこが知りたいよね」と思う質問が飛んできました。この答えは…,当日いらっしゃった方限定ということで,ここでは記さないでおきます。

自動化と構成管理にまつわるこれからの取り組み

TISのITインフラ部隊では,インフラ構築/保守/運用の自動化と標準化の推進を私たちの技術戦略のひとつに据えています。その具体策として,下記の2点をPart 1のTIS倉持の講演の中で発表しました。

(1)全社で使えるコード化・汎用化されたパーツを用意すること

(2)それを活用することで効率性・生産性・品質の向上を目指すこと

自動化を推進するときに案件ごとに違う中身の構築をしていては効果が上がりません。繰り返し使うコードを用意することが必要で,つまりそれは標準化するということです。また,1社だけで自己満足的に取り組むよりは,仲間を作って自動化コードを共有した方が効果的に決まっています。自動化コードの“共創”です。オープンソースの考え方と同じです。仲間を作るためには「どうしてこういうシステム構成にするのがいいのか?」という思いを共有ことも必要です。

私たちは,

(1) 実案件で採用しつつ自動化のノウハウとコードを蓄える(積み上げる)活動をしながら

(2) 私たちが考える「標準(推奨)構成のための“参照モデル”」をまとめようとしています。

成果がある程度まとまってきたら,これらを一般も公開していこうと考えています。

関連リンクなど

エンジニア採用中!私たちと一緒に働いてみませんか?