AWSによるDevOps導入の事例

横河電機株式会社（以下、「横河電機」という。）は、AWSによるDevOpsをどのように実現したのでしょうか。

DevOpsは意味が広い言葉なので、以下、定義しながら説明します。

DevOpsの対象となるソフトウェアは何か

DevOpsの対象は、プラント向け統合生産制御システムCENTUM　VP （センタム、以下「CENTUM」という。）のソフトウェア部分です。CENTUMは、機器、ソフトウェア、コンサルティング、エンジニアリングから成っている大規模なソリューションで、40年以上の歴史を持ち、世界中に出荷されています。弊社の中核商品です。

Devは誰か？

Devに相当するのは、IAシステム＆サービス事業本部システム開発センター システムソフトウェア技術部（以下「IA-SS システム開発センター」という。）のCENTUMソフトウェア開発部門です。

Opsは誰か？

Opsに相当するのは私が所属するIA-SS システム開発センターのインフラ開発部門です。私たちは、開発部門からソースコードを受け取り、ビルドし、テストした上で、出荷可能な状態にパッケージします。メンバーは私を含めて数名。CENTUMソフトウェアの開発期間は、3ヶ月から1年程度で、その間継続的に、ビルド、テスト、パッケージ作成を行います。

今回、DevOpsの取り組みとして具体的に何をしたのか？

今回、CENTUMソフトウェアのテスト基盤を、従来のハードウェアから、AWSによるクラウド基盤に置き換えました。これによりテストの品質、効率、実行回数の向上、そしてコスト削減など様々な効果が上がりました。

このテスト基盤は、今後、インフラ開発部門だけでなく、開発部門でも使えるよう拡張していく予定です。実現すれば、開発者ひとりひとりが、Infrastructure as Codeによる「マイ・テスト環境」を持つことになります。自分の書いたコードを、自由に気軽にAWS環境の中でテストできます。テストを自動化することにより、「不具合の早期発見による品質向上」という効果が上がることを期待しています。

まずインフラ開発部門（Ops）でAWSによるテスト基盤を整え、それを開発部門（Dev）へ拡張する。この取り組みを私は「Opsから始めるDevOps」と位置づけています。

CENTUMソフトウェアのテストにおける、DevOps導入前の課題について教えてください。

前提から説明しましょう。CENTUMソフトウェア部分のテストでは、次の3点が本質的な困難になっています。

困難1.「数百台のコンピュータで稼働する大規模システム」

CENTUMはプラントで使われる大規模システムです。ソフトウェアは、ネットワーク接続した数百台のコンピュータ上で稼働します。このためソフトウェアテストも、それに相応する大規模な環境で行うのが望ましいといえます。

困難2.「数世代前との互換性も視野にいれる必要がある」

一般論として、工場やプラントでは、ソフトウェアを長期間にわたり使い続ける傾向があります。CENTUMは初代CENTUMの発売以来、すでに42年が経過しましたが、数世代前のバージョンもまだ現役で稼働しています。つまりCENTUMのテストは、現行のOS、最新のハードウェアでの動作を確認するだけでは不十分で、以前のバージョンとの互換性も視野に入れる必要があります。テストは様々な顧客環境、要望を「先読み」して、広範囲に行うことが求められます。

困難3.「火気や危険物を扱う場所でも使われる製品であり、テストへの要求水準が高い」

CENTUMは石油化学プラントなど火気や危険物を扱う工場にも導入されています。極論すればCENTUMのバグ、誤動作は、業務非効率を招くだけでなく、重大な事故にもつながりかねません。出荷前テストも、センシティブな場所で使われるソフトウェアとして、入念に行う必要があります。

課題1.「調達のコストとスピードの問題、ハードウェア保管スペースの問題」

PC数十台とはいえ、まとめて調達すれば、けっこうな価格になります。またテスト中およびテスト終了後の、パソコンの保管場所の問題もあります。PC数十台を購入すると、会計上は「資産」として計上されます。資産を調達する場合、事前に多くの申請書類を書く必要があります。そのペーパーワークに費やす時間でテスト時間が少なくなると言うジレンマも感じていました。

課題2.「人の増員にインフラの調達が追いつかないことがある」

テストが遅れたとき、テスト要員を緊急に増やすことがあります。ところが、人は一週間で確保できるのに、パソコンなどテスト環境は調達に二ヶ月かかるということがあります。ハードウェアに頼っているかぎり、人はいるのにインフラが無いせいでテストできない、という何とも歯がゆい状態が起きてしまうのです。

これらの慢性的な課題の解決に取組んでいるときに、Infrastructure as Codeという手法を知りました。インフラ環境をコードで記述し動的に確保する手法です。これでテスト環境を作れないか。さっそくサーバー構成管理ツールの"Chef"をダウンロードして試しました。これは使えると確信しました。さらに情報収集を続ける中でDevOpsという概念に出会い、なるほどこの考え方なら開発部門とテスト部門が「最終製品の品質を上げる」という共通の目的に向けて統一行動できる、と納得しました。Infrastructure as CodeやDevOpsを行うなら、テスト基盤をクラウド化、AWS化するのが合理的です。AWSの活用にも自然に関心が湧きました。

その後、「情報システム部門とサーバーワークスの主導によるAWSの導入・活用」が進んでおり、使用法や調達方法のガイドラインもすでに確立済みであることを知りました。さっそく情報システム部門にサーバーワークスを紹介してもらい、テスト基盤のAWS化に着手しました。

現在、AWSによるDevOpsテスト基盤は、どの程度まで進んでいますか。

現在はAWSのインスタンスで言うと数台～数十台の規模の環境でテストを行っています。クラウドなので「テストに必要なときに必要なだけ使う」という運用です。AWSならテスト要員を増やしたときでも、サーバー増設は瞬時に可能です。また「資産（ハードウェア）」でなく「費用（サービス利用料）」として導入できるので、調達もスピーディです。

今のところ数十台規模ですが、今後、必要に応じて100台、200台規模のテスト環境も構築する予定です。最初の頃は「AWSテスト環境、目標100台！」と思っていました。これがハードウェアなら100台のテスト環境など、「ありえない！絶対に面倒見切れない！」と思うところです。その思考のクセがあったので「もし100台規模でAWSテスト環境が構築できたらスゴイ」と思い込んでいました。

しかしクラウドの場合、数十台でも100台でも500台でも、調達の手間に本質的な違いはありません。極論すれば、申し込みフォームで台数指定するとき「50台」と指定するか「500台」と指定するか、それだけの違いにすぎません。

ハードウェアで100台のテスト環境を作るとなると、調達費用や保管のコストで、TCOは膨大になります。それも「100台のテスト環境などありえない」と思い込む理由の一つでした。しかしAWSならばハードウェアと比べ、およそ10分の1のコストで導入できます。不要になったら使用をやめればよいだけなので、保管のコストも生じません。100台だろうが500台だろうが恐れることはない。今はそんな心境です。

サーバーワークスを起用せず、自力でAWS DevOpsを構築する、ということは考えませんでしたか。

いえ、それは全く考えませんでした。

あくまで個人的な意見ですが、私は「100パーセント内製で工数削減」という方針には懐疑的です。よくネットの記事で「全部、自分でクラウド化したので、コストは大幅安」という記事を見かけます。しかし、あくまで推測ですが、おそらく試行錯誤の過程で「EC2インスタンスをオーバースペックのインスタンスタイプで常時起動していたせいで、膨大なコストが…」といった失敗が一度や二度はあるのではないでしょうか。また、そもそもコストを削減できる方法に気づいていないケースがあるのではないか、と思うのです。

その試行錯誤を通じて社内にノウハウが貯まるんだという考え方もありますが、私はAWSのプロを目指しているわけではないので、そのノウハウが貯まることにあまり価値を感じません。

工場の生産制御システムという「安全・確実」が大原則のシステムに関わっているせいか、たとえテスト環境であっても、構築・運用は計画的に確実に進め、落とし穴は事前に認識して嵌まらないようにし、全てを円滑に進行させるのが本筋だと考えています。

専門家が存在する分野ではその意見を聞きながら進めるのが得策だと思います。すべて独力で行った場合、大げさにいうと「車輪を再発明する」ような無駄な努力、あるいは「絶対に無理筋の不可能事に挑戦しつづける」という愚に陥る可能性があるからです。

これまでAWSでDevOps環境を構築していく中で、できないことを開発しようとし続けてしまったり、無駄遣いしてしまったりといった失敗をした経験はありません。それはやはりサーバーワークスという専門家の支援があったからだと思います。

これまで共に仕事をしてみて分かった「サーバーワークスへの評価」をお聞かせください。

サーバーワークスは「高いコンサルティング力、情報提供力」「こちら側の事情への理解力、対応力」「単なるAWS構築屋に終わらない高い志」の3点を評価しています。

良い点1.「高いコンサルティング力、問題解決力」

AWSはただ仮想サーバーを立てるなら簡単ですが、本格的に活用するとなると、その技術仕様、料金仕様をよく読み解いて使う必要があります。正しく使うにはけっこう落とし穴の多いサービスだということです。こうした落とし穴は、すべてサーバーワークスのアドバイスにより回避できました。サーバーワークスは、こちらが「やりたいこと」「解決したい課題」を伝えたとき、AWS以外にも様々なクラウドサービスやソフトウェアの情報提供を通じて、総合的な解決策を提示してくれます。直ちに解決策が見当たらないときでも、「できない、無理です」と即答するのではなく、必ず「調査」をして、できる方法、代替案を模索してもらえるので、依頼する側にとって信頼感があります。

良い点2.「こちら側の事情への理解力、対応力」

組織の中で施策を展開する場合、真っ直ぐ突き進むだけでなく、様々な事情、内部環境変数を考慮しないと最適な行動がとれません。サーバーワークスは、それら「社内都合」を良く理解し、それに合わせた提案、行動をしてくれる点が助かります。

良い点3.「単なるAWS構築屋に終わらない高い志」

ここでいう「AWS構築屋」とは、AWSのサーバー（インスタンス）1つを構築するごとに収益が得られる業態のことです。この場合、AWSのインスタンスの構築数が多いほど、収益も増えます。しかしサーバーワークスの担当者からは「そういう『人形焼き屋』のようなビジネスをするつもりはない。あくまで『問題解決』を提供し、そこへの対価を得ていく」と明言がありました。最初は正直「本当かな」と思いましたが、実際に共に問題を解決していく中で、「本気でそう考えているんだな」と、真摯な姿勢を実感するようになりました。

現在、DevOpsを念頭においたAWS導入を検討している企業担当者に向けて、先行ユーザーとしての気づき、アドバイスなどあればお願いします。

いくつかあるので順に述べます。

気づき1.「テスト環境とクラウド環境はコンセプトが真逆」

「発売前の」ソフトウェアをテストするための環境は「閉じる」ことを念頭に構成するべきですが、一方でクラウドは本質的に開放系のサービスです。この二律相反に適切に対処するためにも、AWSの仕様をよく理解して、セキュアに構成する必要があります。

気づき2.「社内でDevOpsという言葉を使わないほうが良いことも」

技術者の中には「DevOps」「Infrastructure as Code」「アジャイル」などバズワード（流行り言葉）に直感的に拒否反応を示す人が一定数います。そうした人と話すときは「テスト基盤の自動化」「コードによるテスト環境の構築」など普通の言葉を使う方が良いでしょう。

気づき3.「バズワードにも一定の関心を払う」

バズワードを嫌う人は「内実を伴わない空虚な流行に振り回されたくない」と考えているのだと思います。もちろん技術者として正しい姿勢だと思います。しかし、その一方で「流行っている新手法、多くの人々が口にしている言葉には、必ず何らかの価値がある」という視点も持ったほうが良いかもしれません。DevOpsなんて自分には関係ないと思わず、関心の窓を少しだけでも開けておくのが良いと思います。

気づき4.「AWSはサポート期限切れOSでもサポートを継続してくれる」

これは補足情報ですが、AWSではWindows OSでサポートが切れても、ある程度はAWS側で面倒を見てくれるので、OSの継続使用が可能です。具体的にはWindows 2003のとき大いに助かりました（※ 詳細はこちら）。もちろんOSは常に最新のものに切り替えていくべきですが、こうした「多少の融通」が効くのは非常に助かります。

今後のAWS DevOpsの取り組みについて教えてください。

開発側にInfrastructure as CodeとAWSによる「マイ・テスト環境」を提供するのは、今後のDevOpsへの取り組みの鍵となる重要なパーツだと認識しています。この将来像を見すえて、引き続きAWS、Infrastructure as Code、DevOpsのノウハウを蓄積していくつもりです。

横河電機ではひきつづきCENTUMをはじめとする自社製品の品質向上に努めていきます。サーバーワークスにはそれらの取り組みを、優れた技術とサポートを通じて支援いただくことを希望します。今後ともよろしくお願いします。