このページの本文へ

前へ 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位

    ITトピック

    実用化が楽しみすぎるスマート技術たち 「長距離ワイヤレス給電」から「室内向け太陽電池」「超音波センサー」まで

  2. 2位

    sponsored

    AIインフラ市場“一強体制”を崩せるか AMDが「Helios」で体現するオープン戦略とフィジカルAIのラストマイル

  3. 3位

    ビジネス・開発

    富士ソフトがエンジニア1万人超を「AIネイティブ」化 実装力を武器にフィジカルAIなど3本柱に注力

  4. 4位

    ITトピック

    IT技術者の8割超「AI生成コードには人間のレビューが必要」/「偽・誤情報を見破れる」と自信を持つ人はICTリテラシーテストの正答率が低い、ほか

  5. 5位

    ITトピック

    6.4万人の熱狂をAIが導く FIFA W杯全スタジアム「デジタルツイン」化が変えた観戦体験

  6. 6位

    デジタル

    買い切り型クラウド「pCloud」がDX総合EXPOへ CEO来日で日本展開を加速

  7. 7位

    ITトピック

    IT技術者の約半数が「AIの進化で転職を意識」/これから起きるのは「SaaSの死ではなく変容」/バックアップ市場は堅調に成長、ほか

  8. 8位

    sponsored

    「IT機器が高すぎる」「熟練メンバー不在で分からない」… 情シスさんの“現場の悩み”をエンジニア3人に聞いてみた

  9. 9位

    Team Leaders

    SharePointリストへの登録データを、CSVファイル形式に成形/変換して自動保存する方法

  10. 10位

    TECH

    攻撃するAIと防御するAI 日本企業のセキュリティ対策にいま何が必要か?

集計期間:
2026年07月15日~2026年07月21日
  • 角川アスキー総合研究所