このページの本文へ

前へ 1 2 次へ

事例に厚みが増したAWS Summit 2017レポート 第7回

Dockerコンテナ+ECR、インフラ自動化など、サービス可用性を最大化する方法

「AWSだって壊れる」を前提に考えた可用性向上策、リコー事例講演

2017年06月13日 07時00分更新

文● 大塚昭彦/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 5月31日の「AWS Summit Tokyo 2017」では、法人向けテレビ会議システムのサービス提供基盤としてAWSを活用しているリコーの梅原直樹氏が、インフラ障害の発生を前提としたサービス可用性の向上策について講演した。AWS移行のタイミングで、Dockerコンテナやデプロイ自動化などに取り組んだという。

「AWS Summit Tokyo 2017」で講演した、リコー オフィスサービス開発本部 SI開発センター 第四開発室 クラウドPFグループの梅原直樹氏

講演タイトルは「サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して」

グローバル展開するテレビ会議システムのバックエンドをAWSへ移行

 「RICOH UCS(Unified Communication System)」は、ポータブル型専用端末やPC、スマートデバイスなどを使って利用できる、多拠点対応の法人向けテレビ会議システムだ。バックエンドサービスを、顧客内に設置するオンプレミスシステムではなくクラウドサービスとして提供しているのが特徴で、同社ではこのプロダクトを日本国内だけでなくグローバルに展開している。

「RICOH UCS」は同社がグローバルに展開するビジネス向けのテレビ会議システムだ

 RICOH UCSのバックエンドサービスを支えるインフラとして、当初およそ5年間はリコーのデータセンターに設置したプライベートクラウドを、そして現在はAWSを利用している。1年ほど前にDRサイトからAWS移行を開始し、昨年(2016年)12月からはメインサイトとしてAWSを利用、そして今月(2017年6月)には移行を完了する。

 オンプレミスのプライベートクラウドからパブリッククラウドへ移行した理由について、梅原氏は、コスト高であったこと、物理リソースの追加や削除が柔軟でなかったこと、グローバルに拠点を展開して高品質のサービスを提供したかったことなどを挙げる。現在では、AWSがグローバルに持つ16リージョンのうち、11リージョンを利用しているという。

RICOH UCSのバックエンドシステム。映像配信サーバーはグローバルに分散し、顧客が最寄りのサーバーに接続することで遅延を最小化する

「止めてはいけないサービス」と「必ず壊れるインフラ」の矛盾

 グローバル展開するRICOH UCSは、各国のビジネスタイムを考えると24時間365日、いつでも利用できなければならない。さらに、動画/音声の品質劣化や通話の切断といったサービス障害を起こさないことも重要だ。

 「たとえば、お客様が大事な遠隔商談をしている最中に、テレビ会議の品質が劣化したり映像が途切れたりしてしまったら問題だ。つまり、RICOH UCSは『とにかく切れてはいけないサービス』だと言っていい」(梅原氏)

 しかし、サービス品質保証は永遠の課題だ。特に、インフラについては「『壊れない』という前提で考えてしまいがち」(梅原氏)だが、実際には障害は必ず起きるものだ。実際、リコーでは2015年にオンプレミスのインフラで大規模障害を起こしてしまい、広範囲な影響を及ぼしてしまった苦い経験があると、梅原氏は振り返る。

リコーでは2015年に大規模なインフラ障害を経験し、サービスへも影響を及ぼしてしまった

 それならば、AWS/パブリッククラウドへの移行により可用性が向上し、インフラ障害を考慮しなくても済むようになるだろうか。梅原氏は、オンプレミスインフラ障害の反省を込めながら「そうは思わない」と語る。「やはり『インフラは必ず壊れる』という前提に立ち、マインドチェンジしていく必要があるはず」(梅原氏)。

 AWS移行を契機にサービス可用性を向上させるために、梅原氏は障害発生要素をレイヤーに分けて考えた。アプリケーションやサーバーレイヤーの障害と比べ、データセンターやリージョン、あるいは全リージョンに及ぶ障害の発生頻度は低い。それでも、絶対に障害が発生しないというわけではない。事実、今年2月にはAWSが米国でリージョン障害を起こしているし、昨年4月にはGoogle Cloud Platformが全リージョンに及ぶ障害を起こしている。

リージョン単位での大規模障害はAWSでも発生している

 こうした検討の結果、リコーでは、コスト的にも技術的にも現実的なデータセンター単位の障害について取り組み、可用性を向上させていくことにした。

 「障害は必ず起きるので、いわゆる『Design for Failure(障害を想定した設計)』の考え方を採用する。データセンター1つが丸ごとダウンしても、ほかのどこかでサービスを提供し続けられる環境を実現する。さらに可用性を高めるためには、障害検知を早くして、早く直すことが重要なので、自動復旧の仕組みを採用する。加えて、新規インフラをデプロイする際のダウンタイムもゼロにする」(梅原氏)

リコーが目標とした可用性レベルは「データセンター単位の障害でも復旧できるサービス」

前へ 1 2 次へ

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事

アクセスランキング

  1. 1位

    TECH

    フォーティネットの「SSL-VPN廃止」 IPsec移行と脱VPN、それぞれの注意点を総ざらい

  2. 2位

    ビジネス・開発

    いますぐ捨てたいITサービスは? AI推しにそろそろ飽きてません? 情シスさんのホンネを「ゆるっとナイト」で聞いた

  3. 3位

    sponsored

    完全自動運転の実現へ、チューリングが開発基盤にGMO GPUクラウドを選んだ理由

  4. 4位

    ITトピック

    「AI導入で人員を減らしても収益は増えない」その理由/「専任情シス不在」中小企業の3社に2社/ユーザーアカウント流出が加速、ほか

  5. 5位

    ソフトウェア・仮想化

    「SaaSの死」の影響は感じない ― グローバル以上に好調な日本市場、ServiceNow鈴木社長が語る

  6. 6位

    Team Leaders

    Power AutomateでSharePoint APIを使う ― SPOリストを自動作成するフローを作ろう

  7. 7位

    TECH

    「蟻の一穴」となるリモートアクセスVPNの脆弱性 ZTNA/SASEはなぜ必要か?

  8. 8位

    エンタープライズ

    基盤も古いし、コードも酷い! そんなクエストにGitHub Copilotで試行錯誤しまくった「みんな」こそ最高

  9. 9位

    ソフトウェア・仮想化

    AIエージェントを野放しにしない ― ServiceNowは“AI司令塔”で自律とガバナンスを両立

  10. 10位

    ソフトウェア・仮想化

    日本の自治体がみんな使っている「ManageEngine」 IT運用のすべての課題解決を目指す

集計期間:
2026年05月14日~2026年05月20日
  • 角川アスキー総合研究所