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

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

著者

荒井亜子

[TechTargetジャパン]

印刷する

インフラはコードで徹底的に自動化

　移行に当たっての2つ目のポリシーは、インフラ構築の作業を徹底的に自動化することだ。オンプレミスで稼働していたインフラは、AWS移行の際にその構成をコードで管理可能（Infrastructure as Code）にし、自動構築できるようにした。「インフラは一度作って終わりではない。われわれも何度作り直したか分からない。だからインフラの構築は自動化した方がいい」と梅原氏は述べる。インフラ構築の自動化が特に役立つのは、開発環境やステージ環境といった、必要なときに都度立ち上げる環境だという。

　自動化には、AWS CloudFormationと、AWS CloudFormationのオープンソースの支援ツール「Kumogata」を使用した。Kumogataによって、制約が多く冗長になりがちなAWS CloudFormationの設定に利用する「テンプレート」の記述を簡略化できる。具体的には、AWS CloudFormation用テンプレートのデータ形式として広く利用されているJSONの代わりに、スクリプト言語「Ruby」ベースのドメイン固有言語（DSL）でテンプレートを記述できるようにした。その結果、JSON形式では 6万行だったコードが1万6000行にまで減り、Infrastructure as Codeの実現を容易にした。

　Infrastructure as Codeの一環としてリコーは、開発環境の自動起動／削除を可能にした。午後8時に強制シャットダウンをして、翌朝午前8時に立ち上げる、といった具合だ。こうすることで、AWSの稼働時間、つまりコストを節約できる。またインフラ構築がコードベースになったことでインフラの状況を可視化でき、バージョン管理が可能になった。インフラに不具合があれば作り直せば元に戻る安心感もあり、デプロイの安全性が向上した。システムのアップデート時には、全インスタンス（仮想マシン）を一斉にアップデートするのではなく、リソース単位でインフラを刷新してデプロイするアプローチをとっているので、事前にテスト済みのインフラを利用することができる。

　梅原氏がInfrastructure as Codeの欠点として挙げるのは「インフラを一から構築するので、デプロイに時間がかかること」だという。これまではアプリケーションを更新するだけで済んでいたが、インスタンスを立ち上げてからコンテナを起動してアプリケーションが稼働するので時間がかかる。ただし、そのデメリットを踏まえても「安全性は高くお勧め」だと考えている。

運用して分かったこと、インフラとアプリに境界はない

　インフラが変わったことで、アラートのパターンやAWSの“癖”をつかむまで不安はあったと梅原氏は明かす。AWSのネットワーク速度が低下すると、コンテナからデータベースサーバへ接続できなくなることもあったという。

とはいえ半年間運用してみて、「可用性は向上し、大規模な障害からは解放された。自動復旧にも幾度も助けられた」という。

　梅原氏は、システムがIaaS障害に強い設計になったことで、可用性のボトルネックがアプリケーション側に移っていることを実感するという。「例えばコネクションを常時張り続ける映像配信サービスで、インフラ側の工夫だけで切断を回避するのは困難。インフラ障害は必ず起きるし、インフラ設計と運用だけでカバーするのには限界がある。インフラ障害を考慮してアプリケーション側も改善をしていく必要がある」と述べる。