旭硝子は現在、基幹系システムをAWSに移行している。取り組みを進める中で、数々の“壁”に直面した。導入の初期段階で直面した壁と乗り越え方を、情報システムセンターのメンバーが赤裸々に明かす。

 旭硝子(以下、AGC)では、2015年から基幹システムでパブリッククラウド「AWS(アマゾン・ウェブ・サービス)」を使い始めた。現在、物流や販売などを担う国内向け基幹システムを、AWS のI a aS(インフラストラクチャー・アズ・ア・サービス)、「EC2」上に移行中だ。本格稼働予定は2016年春。2018年までに、基幹システムの7~8割をクラウドに移行する計画だ。

 今回から3回にわたって、実際にAWSを導入したユーザー企業として、AGCの情報システムセンターが経験してきた“壁”とその乗り越え方をお伝えしたい。第1回はAWSの導入決定から利用基盤を整備するまで、第2回はAWS活用や社内展開に当たって直面した課題、第3回は「攻めのIT」を実現する取り組みについて取り上げる。

最初の壁はサービス選定

 当社がAWSの導入を検討し始めたのは2014年。メインフレーム上で動作していたあるシステムがハードウエアの保守切れを迎えることがきっかけだった。欧州SAPのERP(統合基幹業務システム)を採用して一から作り直すことになり、その動作環境としてオンプレミスとクラウドのいずれが最適かを検討した。

 クラウドを選択した主な理由は、「システム開発/運用のコストや作業負荷を下げたい」「現実的な金額でBCP(事業継続計画)対策を実施したい」の2点。いずれもクラウド活用の利点として代表的なものだ。長期にわたって保守/運用し、万全なBCP対策が求められる基幹系システムこそ、クラウドのメリットが生かせると考えた。

 最初に直面した壁が、どのクラウドサービスを選ぶべきかだった。昨今のクラウドブームのおかげで、一般のユーザー企業では把握しきれないほどクラウドサービスの選択肢は多い。

 我々にとって、クラウドサービスの選択は失敗できない重大な作業だった。基幹システムのプラットフォームとしてIaaS環境を用意するのは、オンプレミス環境のデータセンター設計に近い検討が求められる。最初に選んだサービスを短期間で切り替えることになれば、一から検討し直すことになるため無駄が大きい。そこで、慎重に検討を進めた。

 とはいえ、選定に多大なコストと時間を掛けたかというと、実はそうでもない。意外にもあっさりと、やるならAWSということに落ち着いた。

 それはなぜか。今になって振り返ると、検討の前段階で、「基幹システムのプラットフォームとして、IaaSに何を期待するか」という“軸”のようなものが、我々の中である程度明確だったからではないかと思う。

 重視していたのは「標準サービスがとにかく充実していること。標準外の個別リクエストには応えなくてよい(むしろ応えようとしない方が良い)」であった。個別の要求に応えてくれるのは一見ありがたいが、その分料金は高くなるだろうし、新サービスの開発スピードも遅くなるはずだ。我々は初めから、移行するシステムのインフラはクラウド側の標準に作り替えるつもりでいたし、どうしても標準外のサービスが必要なら「オンプレミス環境に残せばよい」という考えでいた。

 このほかにも、譲れないポイントが三つあった。まず「日本にデータセンターがあること」。詳しくは後述するが、法律面を考えれば重要な点だった。次に「オンプレミス環境と専用線で接続できること」。ネットワークの安全性を確保するために、この要件は譲れなかった。最後は「セキュリティに関する監査証跡が、標準サービスとして提供されること」。内部統制に関する既存の運用方法は極力変更したくない事情があったため、必須事項だった。

 クラウドサービスを選定していた2014年春時点では、これらを全て満していたのはAWSだけであった。このため、あまり混乱することなく「やるならAWSで、無理なら当面先送り」という結論を得られた。

時間と根気を掛けて

 このように徹底的な調査を実施したのち、担当者は「クラウドを導入しても大丈夫。いや導入すべきだ」との思いを新たにした。だが、これを組織全体の思いにするのは、容易なことではない。これが、我々にとっての次の壁だった。

 上層部などには「基幹システムにクラウドを使って本当に大丈夫なのか?安定するのか?」との不安が少なからずあった。誰にどう話を持っていくか、メリットとデメリット(リスク)をどう説明するかは、会社の規模や業界、IT部門の役割や立ち位置などによって異なる。どこでも通じる“銀の矢”的な解決策はないだろう。

 AGCの場合、時間と根気を掛けてリスクをいかに回避するかについて説明し、社内を説得していった。「なぜ危険か」を説明するのは容易だが、「なぜ大丈夫なのか」を心から納得してもらうことは難しい。

 そこで我々は、(1)法律面の確認、(2)内部統制との整合、(3)セキュリティリスク、(4)その他社内規定との整合性という四つの側面で評価を行い、その結果を説明するアプローチを取った(図1)。リスク評価の結果に100%の保証はないが、多方面から検討することで結果に厚みと納得感を与えたかったのである。

図1 クラウド採用にまつわる検討項目
問題がないことを多方面から確認し、社内を説得した
図1 クラウド採用にまつわる検討項目
[画像のクリックで拡大表示]

データの置き場所は問題にならず

 クラウドにデータを置いて法律的に問題はないのか。これが、最初に検証した問題であった。既に取り組んでいる企業も多いことから、何となく大丈夫な気はする。だが、明確な情報はほとんど手に入らなかった。どのように調べたらよいのか。その方法からして初めは混乱した。

 まず、「日本のデータセンターからはデータを出さない」ことを前提に置くことで、検討範囲を国内法に限定した。その上で、取り扱うデータの種別ごとに、関連する法令を洗い出した。法令に、データの置き場所を限定するような記載や考え方があるか、という観点で確認していった。

 結果、「基本的にデータがどう管理されているかが重要で、それが説明できれば置き場所がオンプレミス環境であってもクラウドであっても問題にならない」との結論を出した。なお、これはあくまでも国内法に限っての結論である。欧州のデータ保護指令など、データの置き場所自体に規定があるケースもある。

 次に調査したのが、内部統制の規定に違反しないかという点だ。システム関連の統制項目を、(A)自社で従来と同じコントロールができる、(B)従来と同じコントロールが可能だが実施者が自社でなくAWSになる、(C)従来と同じコントロールができなくなる、の三つに仕分けた。

 参考にしたのは、第三者によるAWSの調査レポートである。調査結果は、ほとんどの項目が(A)で、一部(B)に該当するものがあった。例えば「データセンターの入退室管理」などは、実施者がAGCからAWSに変わるので(B)となる。問題となるのは(C)だが、これは1項目もなかった。

セキュリティ関連の情報は豊富

 3番目の検討項目となったセキュリティは、クラウド利用の際に多くのユーザーが気にする点だろう。実は、前出の2項目に比べると、力を入れて調査しなかった。というのも、この手の情報は比較的容易に入手できる状態になりつつあるからだ。

 特にAWSは、セキュリティ関連の情報が幅広く公開されている。自社でのAWS活用ノウハウをパッケージ化したNTTドコモのサービス「ドコモ・クラウドパッケージ」のようなサービスを利用する手もあるだろう。

 最後に、社内独自の規定について準拠状況を確認した。情報セキュリティポリシーや、重要文書のバックアップ方針などが一例だ。いずれも、問題がないことが分かった。

 このように、四つの側面で入念に調査し、大きな問題がないことを確認した。これを基に、上層部への説明を実施した。当然ながら、1回で社内の合意を形成できるわけではない。様々な立場・部署の担当者に向けて、3回、4回と説明会を重ねた。じわじわと「クラウドを導入しても大丈夫」との認識を広げ、最終的にクラウド採用の決定にこぎ着けた。

 AGCの場合、クラウド導入の検討開始から決定までに3カ月ほどの時間を掛けた。検討範囲が多岐にわたったため、人と時間を割く必要があった。検討にリソースを費やせたのは、初期段階でAWSでかかるコストをシミュレーションした結果、メリットが明らかになったからにほかならない。改めていうまでもないが、コスト面の評価は重要である。

まずは二つの基礎作り

 AWSの導入が決まったころには、社内外で広く使われるようになるのではないかという手応えがあった。

 そこで早々にAGCグループ全体でAWSを利用することを意識し、二つの基礎作りを実施した(図2)。AGC全体で活用するとなると、IT統制をどう効かせるか、作業負荷をいかに減らすかが課題になると考えたためだ。

図2 AWSの採用決定後に実施した二つの作業
当初から全社展開を意識し、基礎作りに注力
図2 AWSの採用決定後に実施した二つの作業
[画像のクリックで拡大表示]

 基礎作りの一つが、AWSの技術標準の策定だ。AWSが持つ豊富な機能群を活用するには、入念な調査をして利用する機能を選択し、どんな使い方をするかを決める必要がある。新たにAWSを利用するシステムごとに、それぞれの担当者が調査/決定をするのは非効率で、統制も効かなくなる。そこで、ネットワーク、セキュリティ、アクセス管理、バックアップなどに関して、どのサービスや機能をどういう構成・設定で使うか定めた。

 なかでも慎重に考慮したのがネットワークである。パブリッククラウドを企業が利用する上で、間違っても他社と不正に接続できてはならない。AGCは、仮想プライベート空間を作れる「Amazon VPC(Virtual PrivateCloud)」と、オンプレミス環境とAWSを専用線で結ぶ「AWS DirectConnect」を利用した。Amazon VPCでAWS上にAGC専用の論理区画を作り、そこにAWS Direct Connectで専用線接続することによって、AWSを社内LANの延長にあるデータセンター群のように扱えるようにした。

 セキュリティに関する技術標準は、OSより上位の層、OSより下の層(ハイパーバイザー部分)、物理機器の3点で検討した。

 例えばOSより下は、従来でいえばデータセンターのセキュリティに当たる。これを、AWSの独自機能で行うことになるので、綿密に技術標準を定めた。

 仮想マシンの作成(従来ならサーバーの設置)と削除(従来ならサーバーの撤去)をする権限は、「AWS Identityand Access Management (IAM)」とIAMの「ロール」と呼ばれる機能で制御している。作成や削除の作業履歴は、ログを記録できる「AWS Cloud Trail」で保持している。これは、従来ならデータセンターでの作業記録に相当する。

皆が使う機能は共通基盤に

 二つ目の基礎作りは、こうした技術標準に基づいたシステムを手軽に構築できるようにする共通基盤の整備である。どんなシステムでも必ず使う、コマンドやバックアップ、監視の機能をサービスとして設けた。

 コマンドは、手間を掛けて作り込んだ。AWSの標準サービス・機能を組み合わせ、AGC独自のコマンドで呼び出せるようにした。AWSでは標準のコマンドで、仮想マシンの停止/起動やバックアップができる。多数の仮想マシンを管理するのに便利な半面、他のシステムを誤って止めてしまうリスクもある。リスク回避のために、コマンドを実行する人のアクセス権と、個々の仮想マシンに付与した「タグ」と呼ばれる属性データを照合する仕組みを設け、誤操作を防いだ。

 バックアップについては、AWSが標準機能として用意する数種類のバックアップ用コマンドを使うだけでなく、ストレージサービス「AmazonSimple Storage Ser vice(S3)」に専用の仮想マシン経由でファイルをバックアップできるようにした。バックアップしたファイルにはタグを付けて所有者を把握し、その部門に課金できるようにした。

 システム運用に不可欠な監視機能も、共通基盤に設けた。CPUやメモリーなどの性能監視には、AWS標準の監視機能「CloudWatch」を活用。CloudWatchで自動的に保管される2週間分のデータの保持方法を、独自に設計した。OS上のプロセス監視はAWSではできないので、オープンソースソフトを用いて実装した。

大木 浩司(おおき・こうじ)氏
旭硝子 情報システムセンター 電子・基盤技術グループ 主幹
1993年、旭硝子入社。約20年間、基幹システムのインフラ構築に従事。趣味は酒、スキーなど。
浅沼 勉(あさぬま・つとむ)氏
旭硝子 情報システムセンター グローバルIT企画グループ 主席
アクセンチュアにてITコンサルティング業務に7年間従事後、2011年に旭硝子に入社。AWS認定ソリューションアーキテクト-プロフェッショナル。