【レポート】AWS Summit Tokyo 2017: [AGC 旭硝子] クラウドで変わる。インフラ・データセンター・組織のありかた #AWSSummit

aws-summit-tokyo-2017-longlogo

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは、Day2 導入事例トラック 2のセッション、「[AGC 旭硝子]クラウドで変わる。インフラ・データセンター・組織のありかた」をレポートしたいと思います。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

スピーカー:浅沼 勉 AGC 旭硝子 情報システム部 グローバルIT企画グループ 主席

セッション概要:

前回の AWS Summit Tokyo 2015 登壇 から 2 年。クラウドで何が変わったか?何が変えられなかったか?を赤裸々に語ります。基幹システム (SAP 含む) の移行状況、クラウド化を契機としたデータセンタリニューアル、果ては内製化を含む組織文化の変化まで。コテコテの製造業がクラウドでどう変われたか、そのすべてをお話します。

セッションレポート

以下、セッションのレポートです。

AGC 旭硝子について

  • 1907年創業
  • 創業100年を超える
  • 1日に1,8000トン、バチカン市国x3個分のガラスを毎日作っている
  • 生産量は世界一

スピーカーについて

  • 2011年中途入社
  • 前職はSIerに8年ほど在籍
  • AGCにうつってから6年
  • AWS の PSA資格保持

2015年に続く2回目のAWS Summit登壇

  • 2015年のAWS Summitで初登壇
  • 当時のタイトルは「メインフレームからクラウドへ 〜クラウドで情シス文化を変える〜」
  • 当時はAWSをガンガン使っていたわけではなく、これからガンガン使いますよと宣言しただけ
  • 2年経ってクラウド化はどう進んだのか?その振り返りから始める

そのふりかえりから、本セッションを始める

AWSクラウド化の進捗

2015年発表当時

  • 78インスタンス稼働
  • 本番システムはなかった

2017年現在

  • 452インスタンス稼働
  • 基幹系→376
  • 基幹外→76

  • このサーバー台数を多いと思うかは業界による

    • ウェブ系であれば、何百、何千台のサーバーを動かしている
    • 製造業の基幹として考えると、そこそこの規模といえるのではないか
  • 現在は2日に1台位のペースで増えている

まとめ

企画倒れにならずにAWS化が浸透している。

SAP移行について

  • AGCでは多くのSAPシステムが稼働している
  • 2016年1月に第1号のサービスイン
  • 第2号は2017年6月にサービスイン予定
  • 残りのSAPも順次移行予定

コストについて

  • 2015年当時、AWSクラウド化に伴い、コストが落ちそうな気がすると言っていた
  • 実際にコストを削減できたのか?
  • SAPはオンプレ時代に比べ3割のコストダウンを達成
  • AWS化によりDC費用・運用削減費用含めずにサーバーコストだけの比較で3割の削減
  • DCのコストも含めると、削減率は更に増える

AGCのAWS移行戦略

ここからもっとスパイスのきいた話

  • 標準化
  • DC戦略
  • クラウドx情シス

標準化

  • AWSの基幹系:376インスタンス
  • 62システムがAWS利用中(SAP、Oracleなど)
  • 2週間に1回のペースでAWSにシステム移行する意思決定
  • 適用業務・利用ソフトウェア・開発保守ベンダー すべてがバラバラ
  • 移行対象システムはバラバラだけれども、一定のペースでAWS移行できている

超基幹特化型標準化

AGCの基幹システムのAWS移行方針

  • 基幹ではセキュリティが超大事
  • AWSをきちんと理解して100%使いこなせる人は、社員はおろかベンダーでも稀
  • ガイドライン文書をベンダーに渡す方式はやっていない。
  • ガイドラインを一度作成しても、更新されず、古新聞になりがち
  • 過去のSIerの経験から、ガイドラインだけでは拘束力が不十分

ガイドラインではなく社内向けAWS利用環境サービス(“Alchemy”)を作成

  • AWS ではなく Alchemy を用意しましたた、と社内に展開。
  • AWSを生で触らせず、ワンクッション入れる

Alchemy とは?

  • AGC 謹製のAWS利用環境
  • 1アカウントに全システム集約
  • セキュリティに関する設計・設定をユーザにさせない
  • ユーザーにはOS以上だけの操作を許可する
    • NACL/IGW/サーバー作成などはユーザーができない。
  • AWSコンソール作業は基本申請(EC2の起動・停止など限定的な権限だけ許可)
  • 申請は昔ながらのExcel
  • ユーザーからすると、仮想サーバーが渡され、その上で作業
  • アプリ側からすると、オンプレ時代と同じでAWSを意識しなくてすむ
  • インフラ管理はAWS上
  • AWSサーバー管理はAWSインフラチームが管理する

使えるサービスを基幹で使いそうなものに限定

  • EC2
  • RDS
  • S3

この3つができれば、基幹システムは作れる。

CloudAutomator でバックアップ・起動停止管理を行う

請求

  • 請求先が事業部毎
  • 関係会社にも請求出来るようにする
  • 費用分割作業(請求代行)はアウトソーシング

本社以外の多くの企業が使いたいと言ってくれている

拡散性とクラウドらしさのトレードオフ

  • AGCのクラウド移行は、サーバーをAWSに移行しただけ
  • 拡張性(クラウドの移行のしやすさ)を優先し、クラウドらしさはあまりない
  • 拡張性とクラウドらしさは0,1ではなく、パラメーターの振り方
  • AGCはクラウドらしさよりも拡散性に大きくかじをきっている

なぜ拡張性を優先?

  • ハードウェア資産を削減したい
  • アプリ改修したくても、ハードウェアのリプレース時期に、アプリ改修に合わさざるをえないことも
  • アプリ改修を依頼側からすれば、ハードウェアの減価償却はしったことではない
  • 資産管理とアプリのライフサイクルを別にしたい

データセンター内のHW資産は減り続けている

クラウド時代に企業のデータセンターはどうあるべきか?

  • 情シスは企業のカーストでは下
  • データセンターを管理している挟持がある

プレAWS時代

  • 社内のインフラの中核はデータセンター
  • データセンターがハブ

ポストAWS時代

  • DCとAWSやSaaSがつながっている
  • 大事なデータがAWSやSaaSにたまっている
  • DC の役割はへっている

「データのセンター」はどこ?

  • データセンターはもはや「データのセンター」ではない
  • 死守すべきはデータセンターではなくクラウドまでのWAN経路
  • ネットワーク経路にコストをかけるべき

ネットワークセンター

  • ネットワークセンターを利用して,各サービス・拠点とつながるようにした
  • 新DCはフロア単位ではなく、ラック単位契約にした
  • どんどんAWSに移行するから
  • 2016年の6月から稼働

もとのDCはどうなったのか?

  • 最後は分電盤だけが残った

まとめ

AWS移行により

  • ハードウェアのリプレース
  • DCの聖域化

がなくなった

クラウド x 情シス

クライド時代の情シスのあり方

  • 「情シス不要論」でもりあがることも
  • 「情シス不要論」でGoogle検索すると 41,700件 引っかかる
  • 情シスの立場からすると、イラッとするが改めて考え直すと、主張は一理ある
  • “情シス不要論”が出たことを情シスは歓迎すべき

Why Software is Eating the world

  • もともとネットスケープを開発した Marc Andressenが Wall Street Journal で2011, Aug 20に発表
  • https://www.wsj.com/articles/SB10001424053111903480904576512250915629460
  • すべての産業がソフトウェアにくわれている
  • 業種によらず、ソフトウェア化される
  • Uber,AirBnBなど、この予言はだんだん本物らしくなっている
  • ソフトウェアで勝てないと、今後は生き残れない雰囲気
  • 情シスがやるべきは Change

どうChangeするのか?

  • 会社によって変わるべき方向は違う
  • AGCはどうしようとしているの?
  • →PoCセンター

情シスにPoCセンター機能をインストール

  • アイデア→PoC→うまくいったら大規模にシステム化
  • アイデア、PoCまでは自社(内製化)
    • 契約社員、外注だとコスト・基幹的に難しい
    • 外注を使わず自社で素早く何度もやる。
  • うまくいけば、そこから先は SIer or 内製
  • AGCのような年功序列の会社は SIerと組んだ方がやりやすい

Changeできない3大理由

1.手軽にPoCする環境がない

  • AWS が解決
    • AWSとDXでつながっている
    • 100台のサーバーもすぐに立ち上げられる

2.基幹の仕事が多くて暇がない

  • AWS が解決
    • HWを消すほうにシフトし
    • HWの保守/運用が減る

3.アイデアが無い・開発したこと無い

  • AWSを契約してもなんともならない。
  • 去年、ちょっとしたバッチプログラム開発をやってみた。
  • 基幹のマネージメントばかりをやってきた人に初めて開発をやらせたところ、残念なアウトプット
    • 別の会社に開発のお作法のトレーニングをお願いしている

トレーナー付き自社開発

  • スプリント形式で実際の開発を行う
  • スプリントの管理や開発のヘルプは協力会社にお願いしている
  • はじめて3ヶ月たった
  • ベンダー管理しかしていなかった人でも、実際にコードを書いて、Gitで修正できるようになった

AWS教育

  • 業務・テクノロジーの両方の知識が必要
  • 情シスは業務を知っているが、テクノロジーはしらない
  • AWSの最低レベルの知識が何かはわからないので、アソシエイト取得をゴールに設定
  • トレーニングを協力会社にお願い
  • 情シスの20%が取得がゴール
  • キャズムの谷で、取得者が20%を超えれば組織の文化が変わるのではないか

クラウドにして何が良かったの?

  • 一番いいところは“Speed”
  • なぜスピードが重要なのか?
  • デジタライゼーションを推進したい

ビジネスに必要なもの

  • 技術力
  • 環境
  • 時間
  • 情熱 ← どろくさく、一番重要

情熱は大事

  • 「情熱」がもえていられる時間には限りがある
  • やりたいことをいつまでも追い続けられる人はレア
  • ひらめいた、やりたいと思ったときにすぐ使える(=スピード感のある)インフラ・カルチャーがAWSにはある
  • スタートアップとAWSの相性の良さもこのあたり

まとめ

AGCは今後もAWSを使ってビジネスを推進していく。

感想

歴史あるエンタープライズ企業でありながら、時代・価値観の変化に柔軟に対応し、ベンダー任せではなく、情報システム部が主導してシステムのあるべき姿を再定義し、クラウド化の計画と遂行を実践しているのが印象的でした。