古いバージョンのブラウザーを使用しています。MSN を最適にご利用いただくために、サポートされているバージョンをご使用ください。

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

ザテレビジョン のロゴ ザテレビジョン 2017/06/12
「AWSだって壊れる」を前提に考えた可用性向上策、リコー事例講演 © KADOKAWA CORPORATION 提供 「AWSだって壊れる」を前提に考えた可用性向上策、リコー事例講演

 5月31日の「AWS Summit Tokyo 2017」では、法人向けテレビ会議システムのサービス提供基盤としてAWSを活用しているリコーの梅原直樹氏が、インフラ障害の発生を前提としたサービス可用性の向上策について講演した。AWS移行のタイミングで、Dockerコンテナやデプロイ自動化などに取り組んだという。 「AWS Summit Tokyo 2017」で講演した、リコー オフィスサービス開発本部 SI開発センター 第四開発室 クラウドPFグループの梅原直樹氏 「AWS Summit Tokyo 2017」で講演した、リコー オフィスサービス開発本部 SI開発センター 第四開発室 クラウドPFグループの梅原直樹氏 講演タイトルは「サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して」 講演タイトルは「サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して」 グローバル展開するテレビ会議システムのバックエンドをAWSへ移行  「RICOH UCS(Unified Communication System)」は、ポータブル型専用端末やPC、スマートデバイスなどを使って利用できる、多拠点対応の法人向けテレビ会議システムだ。バックエンドサービスを、顧客内に設置するオンプレミスシステムではなくクラウドサービスとして提供しているのが特徴で、同社ではこのプロダクトを日本国内だけでなくグローバルに展開している。 「RICOH UCS」は同社がグローバルに展開するビジネス向けのテレビ会議システムだ 「RICOH UCS」は同社がグローバルに展開するビジネス向けのテレビ会議システムだ  RICOH UCSのバックエンドサービスを支えるインフラとして、当初およそ5年間はリコーのデータセンターに設置したプライベートクラウドを、そして現在はAWSを利用している。1年ほど前にDRサイトからAWS移行を開始し、昨年(2016年)12月からはメインサイトとしてAWSを利用、そして今月(2017年6月)には移行を完了する。  オンプレミスのプライベートクラウドからパブリッククラウドへ移行した理由について、梅原氏は、コスト高であったこと、物理リソースの追加や削除が柔軟でなかったこと、グローバルに拠点を展開して高品質のサービスを提供したかったことなどを挙げる。現在では、AWSがグローバルに持つ16リージョンのうち、11リージョンを利用しているという。 RICOH UCSのバックエンドシステム。映像配信サーバーはグローバルに分散し、顧客が最寄りのサーバーに接続することで遅延を最小化する RICOH UCSのバックエンドシステム。映像配信サーバーはグローバルに分散し、顧客が最寄りのサーバーに接続することで遅延を最小化する 「止めてはいけないサービス」と「必ず壊れるインフラ」の矛盾  グローバル展開するRICOH UCSは、各国のビジネスタイムを考えると24時間365日、いつでも利用できなければならない。さらに、動画/音声の品質劣化や通話の切断といったサービス障害を起こさないことも重要だ。  「たとえば、お客様が大事な遠隔商談をしている最中に、テレビ会議の品質が劣化したり映像が途切れたりしてしまったら問題だ。つまり、RICOH UCSは『とにかく切れてはいけないサービス』だと言っていい」(梅原氏)  しかし、サービス品質保証は永遠の課題だ。特に、インフラについては「『壊れない』という前提で考えてしまいがち」(梅原氏)だが、実際には障害は必ず起きるものだ。実際、リコーでは2015年にオンプレミスのインフラで大規模障害を起こしてしまい、広範囲な影響を及ぼしてしまった苦い経験があると、梅原氏は振り返る。 リコーでは2015年に大規模なインフラ障害を経験し、サービスへも影響を及ぼしてしまった リコーでは2015年に大規模なインフラ障害を経験し、サービスへも影響を及ぼしてしまった  それならば、AWS/パブリッククラウドへの移行により可用性が向上し、インフラ障害を考慮しなくても済むようになるだろうか。梅原氏は、オンプレミスインフラ障害の反省を込めながら「そうは思わない」と語る。「やはり『インフラは必ず壊れる』という前提に立ち、マインドチェンジしていく必要があるはず」(梅原氏)。  AWS移行を契機にサービス可用性を向上させるために、梅原氏は障害発生要素をレイヤーに分けて考えた。アプリケーションやサーバーレイヤーの障害と比べ、データセンターやリージョン、あるいは全リージョンに及ぶ障害の発生頻度は低い。それでも、絶対に障害が発生しないというわけではない。事実、今年2月にはAWSが米国でリージョン障害を起こしているし、昨年4月にはGoogle Cloud Platformが全リージョンに及ぶ障害を起こしている。 リージョン単位での大規模障害はAWSでも発生している リージョン単位での大規模障害はAWSでも発生している  こうした検討の結果、リコーでは、コスト的にも技術的にも現実的なデータセンター単位の障害について取り組み、可用性を向上させていくことにした。  「障害は必ず起きるので、いわゆる『Design for Failure(障害を想定した設計)』の考え方を採用する。データセンター1つが丸ごとダウンしても、ほかのどこかでサービスを提供し続けられる環境を実現する。さらに可用性を高めるためには、障害検知を早くして、早く直すことが重要なので、自動復旧の仕組みを採用する。加えて、新規インフラをデプロイする際のダウンタイムもゼロにする」(梅原氏) リコーが目標とした可用性レベルは「データセンター単位の障害でも復旧できるサービス」 リコーが目標とした可用性レベルは「データセンター単位の障害でも復旧できるサービス」 AWS移行に合わせて「コンテナ技術」や「インフラのコード化」など適用  オンプレミスからAWSへの移行に際して、リコーでは大きく2つのポリシーを定めた。「基本的に同じ構成で移行すること」「徹底的に自動化すること」の2つだ。  ただし、同時に「コンテナ技術の採用」や「AWSのマネージドサービスの積極採用」「インフラのコード化」といった、ドラスティックな変更もここで行っている。運用開始後にドラスティックな構成変更を行うのは難しいので、移行のタイミングが「変更のチャンス」だと梅原氏は説明する。 移行において定めたポリシー 移行において定めたポリシー  実際の移行作業ではまず、オンプレミス(プライベートクラウド)環境において、バックエンドシステムのコンテナ化を進めていった。梅原氏は、Dockerコンテナを採用したことで「可用性向上に大きく役立った」だけでなく、新しいアプリの開発時にサーバー環境(開発言語やバージョン)を気にしなくてよくなった点が大きなメリットだったと語る。  続いて、AWS側にコンテナ基盤を含むインフラを用意する。基本構成は、Dockerコンテナの管理サービスである「Amazon ECS(EC2 Container Service)」とレジストリサービス「Amazon ECR(EC2 Container Registry)」、そして「Amazon EC2」「Amazon ELB」となっている。 AWS側の基本構成。Dockerコンテナ管理/レジストリサービスのAmazon ECS/ECRを利用している AWS側の基本構成。Dockerコンテナ管理/レジストリサービスのAmazon ECS/ECRを利用している  ここでは「EC2インスタンスが壊れた(ダウンした)場合」「インスタンス上のコンテナが壊れた場合」をそれぞれ前提として捉え、対策を行った。  インスタンスが壊れた場合は、AWSの「Auto Scaling」機能が自動的に新しいインスタンスを立ち上げる。さらに「cfn-init(CloudFormationのスクリプト機能)」が、立ち上がったインスタンスの自動再設定を行うため、自動的に元の環境に回復する。またコンテナが壊れた場合は、まずELBによって別の稼働しているコンテナにアクセスが振り分けられるおり、加えてマルチAZ構成の場合はほかのAZでコンテナが立ち上がっているので、いずれにせよサービスが停止することはない。 インスタンス、コンテナとも「壊れる(ダウンする)」ことを前提に可用性向上の対策を行った インスタンス、コンテナとも「壊れる(ダウンする)」ことを前提に可用性向上の対策を行った  さらに、一部のAPIサービスについては「Amazon API Gateway」「Amazon Lambda」「Amazon DynamoDB」を用いて“サーバーレス化”も行ったという。サーバーレス化によって、上述したインスタンスやコンテナの障害、あるいはデータセンター障害といったことを意識する必要がなくなるからだ。「AWSのマネージドサービス利用を極めていくと、行き着く先はサーバーレスになる」(梅原氏)。  一方で、AWSのマネージドサービスだけではうまくいかない部分もあった。梅原氏は、映像配信サーバーには特有の課題があり、単純なヘルスチェック機能やAuto Scaling機能とは相性が悪かったと説明する。これに関しては、グローバルの各リージョンに独自の仕組み(サービスレベルでの監視クライアント)を設け、映像配信サーバーの各系統が利用できるかどうかに応じて切り離し/切り戻しを行うこととした。なお、ここではマルチAZを使うことで、ダウンタイムゼロでの処理を実現している。 RICOH UCSのバックエンドシステム概要。現在、合計でおよそ20種類のAWSサービスを利用しているという RICOH UCSのバックエンドシステム概要。現在、合計でおよそ20種類のAWSサービスを利用しているという  そのほか、MySQLから「Amazon Aurora」への移行による高速フェイルオーバー(停止数分→数秒)、ヘルスチェック値の最適化、自動復帰できないパターンの検証など「1秒でもサービス復旧を早くするために、できることはまだまだ多くある」と、梅原氏は説明した。 「本当に『インフラは1回作れば終わり』なのか」自動化のメリット  もうひとつの移行ポリシーが「積極的な自動化」だ。梅原氏は、移行におけるインフラ構築作業が繰り返し、2回以上に及ぶのであれば、その作業は自動化すべきだと語る。  「考えるべきことは、本当に『インフラは1回作れば終わり』なのか、ということ。実際、わたしたちは何度も作り直している」(梅原氏)  特に、開発環境やステージング環境は、必要なときだけ利用するインフラであり、そのたびに構築するため自動化のメリットが大きいという。また、基本的に作り直すことのない本番環境であっても、インフラ構築の自動化には「障害時の復旧を早める」メリットがある。  リコーでは、設定管理とオーケストレーションツールの「AWS CloudFormation」にオープンソースツールの「Kumogata」を組み合わせて利用し、自動化の基盤を整えている。ちなみに、開発環境は毎晩20時には自動的にシャットダウン、削除され、翌朝8時に作り直される仕組みになっているため、コスト削減やバグ混入のトラッキングなどに役立っているという。 リコーにおけるインフラの自動化(コード化) リコーにおけるインフラの自動化(コード化)  さらに梅原氏は、イミュータブルインフラ化によって「インフラのバージョン管理」が可能になり、インフラ構築の“職人芸”がコード化されたこと、デプロイにおいても「Blue-Greenデプロイメント」が容易にできるようになったことなどを説明した。 可用性は実際に向上、次はアプリ/インフラの両方をふまえた対策へ  本格運用開始から約半年が経過し、梅原氏は「安心材料がたくさんあった」と語る。AWS移行によって大規模障害から解放され、インフラ稼働率は以前よりも向上している。「自動復旧の仕組みを入れているので、実際に障害が起きて自動復旧したケースもたくさんあった」という。  「可用性は実際に向上した。以前のインフラならば停止時間にカウントされていた障害を救うことができたほか、自動復旧にも幾度も助けられた。IaaS障害に強い設計ができたと思う」(梅原氏) 梅原氏は「事実、可用性は向上した」とまとめた 梅原氏は「事実、可用性は向上した」とまとめた  加えて梅原氏は、“可用性のボトルネック”が変わってきたことを実感していると語った。インフラ/IaaS側の対策で大規模障害を抑えることはできている一方で、インフラ側だけでなくアプリケーション側でのくふうが必要となることも増えているという。たとえば、前述した映像配信サーバーの例だ。  「要するに、アプリケーションの特性がこうだからインフラはこう改善しなければいけないとか、逆にインフラがこういう構成だからアプリケーションはこう構築しなければといったことが、さらなる可用性向上につながるのだと最近は考えている」(梅原氏)  まとめとして梅原氏は、クラウドであろうとも「インフラ障害は必ずある」という前提でシステム設計を行うこと、アプリケーションとインフラの双方を理解し、双方を改善していくことの2点を挙げて、講演を締めくくった。 ■関連サイト RICOH UCS 梅原氏 講演スライド

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

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

ザテレビジョンの関連リンク

ザテレビジョン
ザテレビジョン
image beaconimage beaconimage beacon