「サービス全断は絶対ダメ」、可用性第一で考えたテレビ会議のAWS移行（1/2 ページ）

リコーがオンプレミスで運用していた自社製品のテレビ会議システムのインフラをAWSへ移行。可用性向上に徹底的に取り組み、サーバレス化などのクラウド特性を存分に活用した他、インフラ構築の自動化も取り入れた。

公開 2017年06月15日 09時01分

著者

荒井亜子

[TechTargetジャパン]

印刷する

コンテナ化による可用性向上《クリックで拡大》

　「RICOH Unified Communication System」（以下、RICOH UCS）は、インターネット経由で接続するグローバル対応のテレビ会議システムだ。専用端末の他、Windows、macOS、iOS、Androidなどの搭載端末で利用できる。リコーはRICOH UCSの基盤を、2017年6月中にAWSへ完全移行する。ビジネス向けテレビ会議システムは商談に利用されることもあり、安定稼働が求められる。そんなシステムをどのようにAWSへ移行したのかは、ユーザー企業にとっても参考になるかもしれない。2017年5月31日に開催された「AWS Summit Tokyo 2017」で、リコーのオフィスサービス開発本部に勤めるインフラリーダー、梅原直樹氏が講演した。

併せて読みたいお薦めの記事

AWS Summit Tokyo 2017レポート

「サーバレス」がクラウド運用を変える

インフラ自動化のススメ

安定性命のテレビ会議システム

　RICOH UCSのシステムは2011年8月から2016年6月までオンプレミスで稼働していた。ところがリコーグループ全体としてオンプレミスからクラウドへ移行する方針を掲げていたこと、オンプレミスのシステム運用コストが高かったこと、リソースの追加／削除を柔軟にしたいといった動機から、RICOH UCSのシステムをクラウド化することに決定。2016年6月に災害対策（DR）用にAWS利用を開始し、2016年12月にはメイン環境を移行、2017年6月中にAWSへ完全移行する。

　RICOH UCSは、グローバルで商談などビジネスの重要な局面に利用されるシステムだ。世界中のビジネスアワーを想定すると24時間365日の稼働が求められる。

　「大切な遠隔商談の途中に映像が途切れるようなことはあってはならない」と話す梅原氏だが、実際リコーでは2015年に、RICOH UCSのシステムが稼働するインフラで大規模障害が起こった。仮想サーバをいくら冗長化していても、インフラ障害が起これば全てが無駄になる。「システムの障害はエンドユーザーに大きな損失をもたらし、RICOH UCSへの信頼も低下させる」。こうした事態が二度と起こらないよう、今回のAWS移行では、とにもかくにも可用性の向上を目指した。もちろんAWSへ移行して終わりではない。「AWSへ移行したからといって可用性が向上するとは限らない。インフラは壊れる前提で考える」と同氏は話す。

　可用性向上と言っても、対策はさまざまだ。障害の種類は、アプリケーション障害、サーバ障害、データセンター障害、リージョン障害、全リージョン障害と、障害が発生する箇所や規模によって分けることができる。リージョン障害や全リージョン障害といった大規模な障害の場合、起こったときの被害は甚大だ。AWSだけでなく他のクラウド事業者でも、リージョン障害や全リージョン障害は実際に起きている。梅原氏は「頻度が低くても障害は必ずある」と考えている。ただし、全ての障害に対策を取るのは大変かつ多額のコストがかかる。RICOH UCSでは、まずはデータセンター障害に対策の目を向けた。

　梅原氏はIaaS障害を想定し「データセンターが丸ごと停止してもシステムが動き続けることを目指す」ことにした。そのために「障害検知を速くする、速く修復するために自動的に復旧させる仕組みを作る、デプロイ時のダウンタイムをゼロにすること」を目標に据えた。

AWS移行の2つのポリシー、「クラウド最適」「自動化」

　移行に当たっては、大きく2つのポリシーを掲げた。1つ目は、基本的にオンプレミスと同じ構成を取るが、コンテナ技術やマネージドサービスを積極的に採用し、移行後にクラウドへ最適化していくこと。2つ目は、インフラを徹底的に自動化することだ。

　移行に当たって梅原氏は、「運用が始まるとドラスチックな（思い切った）変更は難しくなる。移行スピードとのトレードオフにはなるが、大きなシステム変更はなるべく移行のタイミングですべきだ」とアドバイスする。

　RICOH UCSのシステム構成は、テレビ会議システムとしては一般的なものだと梅原氏は述べる。接続要求を受け付けるフロントエンドにロードバランサー（LB）があり、WebアプリケーションサーバとWeb APIサーバ、システムのコアとなる映像配信サーバが並び、その後ろにデータベースサーバ（「MySQL」）が位置する。

　テレビ会議のシステムが特徴的なのは、接続する相手がその都度変わり、接続する相手によってデータセンターの場所も変化するということだ。エンドユーザーのいる場所から映像配信サーバへの距離が近いほど配信遅延が短くなるため、RICOH UCSの映像配信サーバはグローバルに分散させている。データベースサーバとWeb APIサーバへのアクセスは複数のデータセンター間で高い頻度で発生することになる。

壊れる前提でコンテナ化

　一番の変更点は、以前は仮想マシンに構築していたWeb APIサーバ、各種Webアプリケーションサーバをコンテナ化したことだ。コンテナの作成には「Docker」を採用した。AWSのDockerコンテナ管理機能「Amazon EC2 Container Service」（Amazon ECS）が2016年8月から東京リージョンで使えるようになったことも安心材料になったという。

　Dockerのメリットは、コンテナのデプロイ（実行環境への配備）やロールバック（以前のバージョンの復元）が容易なことに加え、システム基盤との依存関係が低く、さまざまなインフラで稼働できることだ。梅原氏も「Dockerさえあれば言語やバージョンを気にせずに開発ができる」と話す。一方で運用実績には不安があった。リコーグループ自体は2～3年前からDockerの本番運用をしているが、RICOH UCSではこれから運用実績を作っていかなければならなかったからだ。

　基本構成は、仮想サーバの「Amazon EC2」、ロードバランサーの「Amazon Elastic Load Balancing」（Amazon ELB）、Dockerイメージ（注）管理の「Amazon EC2 Container Registry」（Amazon ECR）とAmazon ECSだ。アプリケーションやAPIのDockerイメージをAmazon ECRにプッシュするだけでデプロイが可能。Amazon ECSがアプリケーションの役割に応じて稼働コンテナ数を変更する。

※注： Dockerコンテナの実行に必要なファイルや設定などをまとめたもの。

　リコーはインスタンスもコンテナも壊れる前提で、可用性を向上させるための工夫を施した。インスタンスに関しては、先述の構成に加えて、仮想サーバを自動拡張／縮小するAWSの機能「Auto Scaling」と、AWSの構成・管理機能「AWS CloudFormation」、その支援スクリプト「cfn-init」を組み合わせることで、オートスケーリングと自動復旧の仕組みを構築した。コンテナに関しては、Amazon ELBをAmazon ECSと連携することで、壊れたコンテナへアクセスが振り分けられるのを阻止しダウンタイムを発生させないようにした。また同一リージョン内の複数データセンター群（「アベイラビリティーゾーン」）にまたがる「Multi-AZ」構成を取り入れ、万が一コンテナが壊れた際にデータセンター単位で障害が起きても他のアベイラビリティーゾーンで自動復旧し、ダウンタイムゼロを実現できるようにした。

マネージドサービスも積極採用、ただし相性が悪いケースもある

　コンテナと連携するデータベース管理システムは、オンプレミスのときと同様にMySQLをそのまま使用している。ただしデータベースサーバはマネージドサービス「Amazon Relational Database Service」（Amazon RDS）へ移行。これによって内製の運用ツールが不要になり、運用コストが下がったという。こちらもデータセンター障害を考慮するならMulti-AZ構成を組めばよい。

　一方で、データベース構成を移行するときには若干の制約があったという。「特殊な例だが、クロスリージョンの（リージョンをまたいだ）Multi-AZ構成にして、データベースのレプリカを分散保存したかったが、Amazon RDSではそれができなかった」（梅原氏）。システム関連でやりたいことができないときは、システム構成を大きく変えるか、諦めるかのどちらかしかない。今回リコーは構成を変更せずに臨んだという。梅原氏は「システム構成の変更が必要となったときに、変更するのかしないのかで、それぞれのトレードオフを検討することは大切」と話す。

　他にも、AWSのクラウド特性にうまくはまらない点があった。その1つがサービスのコアである映像配信サーバのオートスケールだ。「テレビ会議という特性上、1台でもつながっている端末がある限り、そのリージョンで稼働する映像配信ルータの数を減らすことができない」（梅原氏）。リコーが行ったのは、映像配信サーバの切り離し／切り戻しという運用だ。グローバルのリージョンに監視クライアントを置き、分散している映像配信サーバを1分に1回監視する。正しく動いている映像配信サーバの系統にのみアクセスを振り分けるという方法だ。「いわゆるテレビ会議のロードバランサーの仕組み。これによって、映像配信サーバ単位もしくはアベイラビリティーゾーン単位で障害が起きてもダウンタイムゼロを実現できる」（梅原氏）

映像配信サーバの切り離し／切り戻し

　リコーはこうした課題を乗り越えつつ、システムの改善を重ねている。データベース管理システムは、Amazon RDSからAWSのクラウド特化型データベース「Amazon Aurora」へ変更した。データベース接続用のドライバに、MySQL互換のデータベース管理システム「MariaDB」のJDBCドライバ「Connector/J」を使用し、高速なフェイルオーバー（障害発生時の待機系への切り替え）を実現。「通常は2～3分停止するが、Amazon Auroraは工夫次第で障害発生から最大2～3秒で復帰できる。可用性が向上した」と話す。「障害の検知を速め、1秒でも速く復旧するため」に、自動復帰しないパターンの観測を進め、監視／復旧プログラムを投入しているとのことだ。

次ページへインフラ自動化の方法