クラウド&データセンター完全ガイド:イベントレポート

各業界のユーザー事例が示すAWSの活用分野の広がり

AWS Summit Tokyo 2017

弊社刊「クラウド&データセンター完全ガイド 2017年夏号」から記事を抜粋してお届けします。「クラウド&データセンター完全ガイド」は、国内唯一のクラウド/データセンター専門誌です。クラウドサービスやデータセンターの選定・利用に携わる読者に向けて、有用な情報をタイムリーに発信しています。
発売:2017年6月30日
定価:本体2000円+税

2017年5月30日~6月2日の4日間、東京都内でアマゾン ウェブ サービス主催の「AWS Summit Tokyo 2017」が開催された。プライベートコンファレンスとは思えないほど多数の参加者が押し寄せた注目のイベントから、いくつかの導入事例トラックの講演の模様を紹介する。初期からのAWSユーザーであるIT企業のみならず、歴史のある製造業や大手サービス事業者にも活用の広がりを見せていることがわかる。 text&photo:柏木恵子

旭硝子が挑んだクラウドシフトとそのための標準化

 AGC旭硝子の事例セッションには、同社情報システム部 グローバルIT企画グループ 主席の浅沼勉氏(写真1)が登壇した。講演タイトルは「クラウドで変わる。インフラ・データセンター・組織のありかた」。ガラス製造最大手の旭硝子は、実に創業100年を超える老舗企業である。浅沼氏は2015年のAWS Summit Tokyoにも登壇しており、そのときは、基幹データベースをメインフレームからAWSに移行したプロジェクトを説明している。浅沼氏は、それから2年経った後の状況を以下のようにまとめ、これらを踏まえて、標準化、データセンター戦略、「クラウド時代の情シス」の3つについて言及した。

写真1:AGC旭硝子 情報システム部 グローバルIT企画グループ 主席の浅沼勉氏
  • AWSインスタンス数は2年前の78から452に。そのうち基幹が376で、それ以外が76
  • 2日に1台のペースでインスタンスが増加中
  • AWS on SAPの第1段階が2016年1月に、第2段階が同年6月にサービスイン
  • コストは、オンプレミスでSAPを稼働した場合よりも約30%減(データセンターコストを含まず)

 現在、旭硝子では452のAWSインスタンスで62システムが稼働している。適用業務、利用ソフトウェア、開発保守ベンダーがバラバラのシステムが1つの環境に入っている状態で、しかも2週間に1度のペースで新しいシステムがAWSに移行される。

 「多様なシステムがどんどん増えている中でもスピード感を出す必要がある。そこでポイントとなるのが標準化だ」と浅沼氏。同社は、AWS上でSAPを動かすことを前提とした「超基幹特化型標準化」というデザインを策定。そこでは、「基幹システムで利用するため、セキュリティは強固に」「AWSをきちんと理解して100%使いこなせる人はまれなので、ベンダーを信用しない」「ガイドライン文書だけでは拘束力が不十分」という観点が取り入れられた。

 「ガイドライン文書を渡してもそのとおりやってくれるとはかぎらないし、監査が難しい。また、一度作ったガイドラインは更新されず陳腐化しやすい。特にクラウドはどんどん変わるため、ガイドラインがそれに追いつくのは大変だ」と浅沼氏は指摘。解決策として手がけられたのが「ALCHEMY」と呼ばれる社内向けクラウドサービスである。それぞれの部門ごとにAWSアカウントを契約するのではなく、1つのAWSのアカウントに情シス(インフラ担当)がセキュリティに関する設計・設定を行い、各部門(ベンダー)には文書ではなくサービスを渡す仕組みだ。浅沼氏は特徴として以下の4点を挙げた。

①セキュリティに関する設計・設定
 ユーザーが行わない。情シスが行う。
②AWSコンソール作業は基本申請制
 ユーザー部門にはサーバー起動の権限だけを申請制で渡す。ユーザー部門にとっては、仮想サーバーをもらった後のOSの設定、ミドルウェアの導入、アプリケーションの開発という流れになり、オンプレの作業と変わらない。
③「使えるサービス」を限定
 AWSにはさまざまな機能があるが、ユーザーに提供するのは同社以外のサービスも含めて基幹システムに必要なものに限られている。具体的には、「Amazon EC2+ELB(Elastic Load Balancing)」「Amazon RDS」「Amazon S3」「Cloud Automator」(バックアップ・起動停止用)の各サービスで1つのパッケージになっている。
④費用分割作業はアウトソーシング
 1アカウントに全システムが載るが、コストはシステムごとに負担してもらいたい場合、それを計算するのは繁雑なため、「TerraSky」「BeeX」の請求代行スキームを利用している。社内部門だけでなく関係会社も利用申請ができ、請求代行も利用しているためにうまくまわすことができている。

 ALCHEMYは、スケール可能にはなっているが、サーバーレスアーキテクチャや運用自動化のようなクラウドならではの機能は使っていない。浅沼氏によると、同社がこの方法を採用したのは「ハードウェアをデータセンターからなくしたかった」からだという。

 ハードウェアがあると情シスはそれにまつわる作業が多くなり、サーバーやネットワーク機器の更改など、部門の業務がハードウェアのライフサイクルに縛られてしまう。また、業務部門から機能改善の要求が届いても「来年がハードウェアの更改時期で、そのときにソフトウェアもバージョンアップする予定だから実装を待ってもらいたい」といったことが起きる。

 浅沼氏は、「これは業務部門にとってはまったく意味不明で、あってはならないこと。AWSにシステムを移行すればハードウェアはどんどん減っていき、このような問題が解決に向かう」と語った。

クラウド時代のデータセンター戦略

 これまでの社内インフラは常にデータセンターが主役だった。データセンターをハブにして、さまざまなものが繋がる構成だ。データセンターは最も重要なデータが集積される場所であり、セキュリティのためにそれなりの投資が当然とされてきた。

 しかし、今では重要なデータはクラウドにあるケースが増えている。「そうなると、企業がコストをかけるべきはデータセンターではなく、クラウドまでのWAN経路になる」と浅沼氏は指摘。旭硝子では、2016年6月にデータセンターからネットワーク機能だけを切り離したネットワークセンターを構築。ここに最大のコストをかけ、東西で冗長化している。この構成では、ネットワークセンターに対してすべての拠点・サービスがつながり、従来のデータセンターは1つの拠点の扱いとなる。

 また、ネットワークセンター構築と同時に、従来のデータセンターにあったすべてのラックを新しいデータセンターに移設した。このとき旭硝子はそれまでのハウジング契約ではなく、ラック単位のコロケーション契約を選択している。サーバーは順次、AWSに移行していくことを見越してのことだ。

クラウド時代に情シスは不要か

 情シスの聖域だったデータセンターからサーバーがなくなる。そうなったら情シスの役割はどうすればよいのだろうか。そのような話題がネット上でもよくなされている。浅沼氏は、自身がGoogleで検索してみたところ、「情シス不要論」が約4万件もあったという。しかし同氏は、「不要論が出たことを情シスは歓迎すべきではないか」とポジティブにとらえている。

 浅沼氏は、Webブラウザの「NCSA Mosaic」や「Netscape Navigator」の開発者として知られるマーク・アンドリーセン(Marc Andreessen)氏が2011年に発表した論文「Why Software Is Eating The World」では、競争力の源泉はソフトウェアに移り、ソフトウェア化できなければ生き残れないと記されていたことを紹介。「これが現実になりつつあり、ITの使い方がこれまでは違ってきている。その結果、情シスにやってほしいことが変化する。不要になるのではなく、変わって欲しいのではないか」(同氏)

 情シスが目指すべき方向は企業によって異なるだろうが、旭硝子の場合は、情シスにPoCセンター機能をインストールしたいという構想がある。PoC(Proof of Concept:概念実証)は、新しいアイデアが実現可能か簡易に検証するプロトタイプの前段階のことだ。同社でも当初は「手軽にPoCを行う環境がない」「基幹業務システムの仕事が多くて暇がない」「アイデアがない/開発したことがない」といった懸念があったという。

 環境や業務リソースの不足の問題はAWSの利用で解決が可能だ。旭硝子ではクラウド移行の際、クラウドらしさにこだわらずハードウェア削減に注力したのは、それによってエンジニアの時間を作るためだったという。しかし、アイデアや開発スキルの不足は別問題だ。

 浅沼氏は、「以前は開発したことがない人でも、頑張ればなんとかなる」と思っていたが、実はまったくプログラミングをしたことがない人は作法がまるで分からないため「とんでもコード」ができあがることを経験している。そこで、協力会社と共に以下のような取り組みを行うことにした。

トレーナー付き自社開発

 トレーナー(サーバーワークスと契約)にチームに入ってもらい、アジャイル開発やソースコードのレビューなどをサポートしてもらった。

社内向けAWS教育プログラム

 業務の知識とテクノロジーの両方が分かっていないとアイデアを形にしづらいので、教育プログラムを実施。AWS認定ソリューションのアソシエイト取得を当面の目標にした。

 浅沼氏はクラウド化で何がよかったかについて述べた。「柔軟性、コスト、堅牢性、新しいテクノロジーなどさまざまなメリットがあるが、クラウドの最もよいところは、結局スピードだ。デジタル化を進めるためには、技術力・環境・時間が必要だが、実は情熱が最も重要で、情熱が燃えていられる時間には限りがあり、時間とともに冷めていく。そこで、ひらめいた瞬間、やりたいと思った瞬間に、すぐ使えるというのがAWSのいちばんのメリットだという。

インフラ構築手順のコード化を推進したナビタイム

 ナビタイムジャパンの事例セッションには、同社サーバーグループ プロジェクトマネージャの萱島克英氏(写真2)が登壇した。氏が紹介したのは、2017年3月にモバイル向け「乗換NAVITIME」アプリのバックエンドシステムをオンプレからAWSへ移行した事例だ。

写真2:ナビタイムジャパン サーバーグループ プロジェクトマネージャの萱島克英氏

 乗換NAVITIMEは利用者数が順調に増加し、繁忙期のアクセスを予想しながらのサーバー調達・運用で人的コストが増加していた。また、オートスケールできないため、余剰サーバーを確保する必要がありコストがかさみ、また、インフラ構築作業のコード化が進んでいないため、OSやミドルウェアのバージョンアップに時間がかかる課題もあった。そこで同社は、一部システムで利用しているAWSのメリットが明確になったことから移行を決断した。

 移行方法には、VM Import/Exportを使った移行もあるが、初期コストよりも移行後の運用メリットをとり、アプリケーションをコンテナ化し、Amazon EC2 Container Services(ECS)で運用する方法を選択した。単純な輻輳対策ではなく、Infrastructure as Codeの概念に則った構成にリプレースしつつ、AWSに移行する方針だ。実現したかったのは、「アプリケーションサーバーのオートスケーリング」「インフラエンジニアの運用コスト削減」「リードタイム短縮」の3点で、AWSとDockerを活用した。

 アプリケーションサーバーには、オープンソースの「Ansible Container」を使ってDockerコンテナを作成。コンテナの構成チェックには「Serverspec」を利用した。また、AWS環境構築手順のコード化には、AWSが提供するマネージドサービス「AWS CloudFormation」を利用した。

 「移行後の運用では、ECSやAuroraが便利だった。ECSはデプロイ方法が柔軟で、コンテナの死活監視や再起動はECSがやってくれる。AuroraはデータベースのBlue/Green切り替え(稼働中のサーバーを更新するのではなく、更新済みのサーバーと入れ換える)が簡単に行え、リードレプリカの機能が秀逸だ」(萱島氏)

 AWS移行の効果は大きく、萱島氏は、インフラ構築手順をコード化した結果、環境構築にかかる時間が大幅に短縮できたほか、Dockerを用いたコンテナ化によるアプリケーションのポータビリティ向上、AWSに移行したことで、アクセス数に応じたオートスケールが可能になり、インフラエンジニアの運用負担の減少したことを挙げた。

可用性向上のためのクラウド移行

 リコーの事例セッションには、同社オフィスサービス開発本部SI開発センター 第四開発室 クラウドPFグループの梅原直樹氏(写真3)が登壇し、可用性向上を目的としたAWS活用事例を紹介した。

写真3:リコー オフィスサービス開発本部SI 開発センター 第四開発室 クラウドPFグループの梅原直樹氏

 リコーは、インターネット経由でグローバルなテレビ会議を簡単に行う「RICOH UCS」を提供している。当初はオンプレミス環境でスタートしたが、高くつくコストやリソース追加/削除時のセキュリティ、グローバル接続での問題などの課題を解決すべく、2016年6月より徐々にAWSに移行し、2017年6月にメイン環境のAWS移行を完了した。

 企業向けのテレビ会議サービスの場合、重要な遠隔会議をしている最中に映像が途切れるようなことはあってはならない。可用性向上のためにリコーは以下の要件を定めた。

  • IaaSの障害を想定した設計
  • データセンター全体がサービスダウンしても、別の経路で続けて利用できる
  • 障害検知を迅速に行い、自動的に復旧させる
  • デプロイのダウンタイムをゼロにする

 実現にあたってリコーでは、基本的に同じ構成で移行することにしたが、コンテナ技術を採用することを決定。また、マネージドサービスも積極的に採用することと、オンプレミスで動いていたものをすべてコード化し自動構築を可能にした。

 Dockerでのコンテナ化では、基本構成を「ELB・EC2・ECS・EC」の組み合わせとし、ECRがDev側とOps側のインタフェースを担う。「インスタンスやコンテナは壊れる前提で考えることで可用性を高めていった。インフラのコード化では、当初はCloudFormationを利用していたが、Ruby製ツールのKumogataに変更したことで、コードの行数は大幅に減った」と梅原氏は説明。また、Dev環境は営業時間内のみ自動起動/削除できるようになっていて、20時になると強制的にシャットダウンされる。長時間残業はできないし、毎日構築されるのでバグ混入のトラッキングがしやすいという評価だ。

 本格運用開始して半年経つが、梅原氏によると「可用性のボトルネックが変わってきた」実感があると言う。IaaS障害のような大規模障害ではなく小規模障害に変わり、アプリケーション側の工夫が必要なケースが出てきている。「クラウドではインフラとアプリケーションの境目はないので、互いを理解し自社サービスの特性を理解して改善することが必要だ」(梅原氏)

老朽化した基幹システムをAWSに載せたKNT-CT

 KNT-CTホールディングスの事例セッションには、同社経営戦略統括部部長の小野睦氏(写真4)が登壇した。同社は近畿日本ツーリストとクラブツーリズムが経営統合してできた企業である。オンプレミスで稼働する基幹業務システムが老朽化したことからAWSの導入を検討。「単にリプレースするのではなく、どうでならAWSで“所有から利用”へ切り替えたい」と考えたのがAWSを採用した理由だ」と小野氏は説明。

写真4:KNT-CTホールディングス 経営戦略統括部部長の小野睦氏

 旅行業界は繁閑の差が大きい。そこでKNT-CTホールディングスはAWSに以下を期待したという。

  • 柔軟なシステムの拡大・縮小が可能
  • 短期的なシステム利用に対応
  • セキュリティおよび内部統制基準クリア
  • 基盤コストの大幅な削減
  • 長期利用による継続的なコスト削減効果

 2013年7月にAWS利用を判断し、2017年3月時点での利用状況はVPCが21、EC2が290、RDSが4となっている。コストはAWS移行でオンプレミスよりも下がっているが、数度の料金改定によって当初予測よりもさらに抑えられている。

 実際にAWSを使ってみての効果は、「一言で言うと、気が楽になった」(小野氏)ということだ。AWSは各種グローバルセキュリティ基準に準拠しているため、セキュリティ監査もスムーズになり、Multi-AZ(Availability Zone)でDR/BCP対応も実現した。

 使い始めて3年が経過して、さまざまな気づきが得られたと小野氏。「例えば、オンプレミスでシステム構築するとパートナーが固定して、新しいことに挑戦しにくくなることが多い。クラウドの時代はさまざまなサービスが次々に展開されるので、柔軟に組み合わせて新しいモノを作るという発想に変わった」

 メリットだけでなく、注意が必要なこともあるという。1つは業務確認試験の実施だ。「アプリケーションを変えない移行が多かったが、それでもうまく動かないことがあり、確認試験を行う必要があった。また、AWSには大規模データ移行サービスSnowballがあるが、それを知らなかったため時間がかかってしまった。定期的な性能評価も重要だ」(同氏)

 小野氏は、オンプレミスの時代にはなかった文化としてユーザー会の有用性も言い添えた。「異業種の話を聞くことも勉強になるし、業界によらず苦労している点は似ていることが多い」

周回遅れからのクラウド挑戦

 日立物流のセッションには、同社情報基盤統括部 部長補佐の田代肇氏(写真5)、情報子会社である日立物流ソフトウェア システム事業統括本部ネットワークソリューション部 部長の吉田佑一郎氏(写真6)の2人が登壇した。

写真5:日立物流 情報基盤統括部 部長補佐の田代肇氏
写真6:日立物流ソフトウェア システム事業統括本部ネットワークソリューション部 部長の吉田佑一郎氏

 日立物流の拠点はグローバルで118社776拠点と多く、荷主はグローバル化している。そのグローバル事業を支えるシステムの1つが、「GWMS(Global Warehouse Management System)」という在庫管理システムだ。これは当初、日本国内の自社データセンターで稼働し、グローバルにサービス提供していた。しかし、地震などの大規模災害でGWMSが止まると、海外で利用している荷主のサプライチェーンも止まってしまう。そこで、2014年4月にGWMSの提供場所の見直しを決定した。プロジェクトの目標は以下のとおりだ。

  • 米国、アジア、中国(3極)からサービス提供
  • グローバルDRも同時構築
  • 1.5年以内で3極を立ち上げる予定
  • B2Bレベルの品質(業務停止なし)
  • コストは既存のオンプレミスより抑えたい

 田代氏によると、いくつかの選択肢を検討したところ、すべての要求を満たすのはAWSのみだったという。しかし、AWSの経験は皆無で知識やノウハウがない。そこで、まずはAWS東京でGWMSを稼働させるスモールスタートを実施した。

 といっても、簡単に進んだわけではない。システム子会社としては「経験・スキルが不足するIaaSを使って止まっても責任が持てない」(吉田氏)わけで、日立製作所の協力や日立物流もリスクを共有することで合意に至り、AWSの採用決定にこぎつけた。大組織ゆえの決定の遅延で、スケジュールはこの時点で2カ月遅れとなった。

 さらに、アプリケーション稼働検証の段階でも、情報子会社の側では「オンプレミスのときと動作が違う。本当に正常に稼働するかわからない」とネガティブだった。日立の技術支援などでそれがポジティブに変わるまでにもやはり2カ月かかった。

 超えるべき壁は3つで、技術者のマインド、技術習得、変化への追随だ。しかしながら、技術者は本来新しい物好きな人種なので、やってみると「けっこう面白い」ということになり、今ではすっかりAWS推進派になっているという。

 また、日立物流ではマルチクラウド戦略をとっており、途中でSAP R/3の本番環境を他社クラウドからAWSに移行した。この時に経験した注意点が以下の点だ。

  • インスタンスタイプの検討は慎重に、いつでも変えられると安心しない
  • ディスクのウォームアップ時間も事前検証しておけばより安心
  • インスタンスタイプごとにIOPSの上限等が細かく指定されているのでよく把握しておく

 その他、オンプレからクラウドへの移行を「ただのインフラ形式の変化」ではなく、「仕事のやり方が変わる」ととらえた組織改革が必要だという。最後に吉田氏は、どんな質問にも丁寧に、適確に対応してくれたAWSのサポート対応はピカイチだと思うと述べてセッションを締めくくった。

クラウド&データセンター完全ガイド2017年夏号