ブログ

こんにちは、別府です。

今回はクラウドサービス運用の話をしたいと思います。

Aipo.com では、年間約 80 回ほどのアプリケーションアップデートを行っています。飛び抜けて大きい数字ということでもないのですが、顧客に新しい機能、価値をいち早く提供したい、といった想いのもと、頻繁なバージョンアップについては重要視をしています。また、脆弱性が発見されたら迅速にセキュリティパッチをサーバーに反映させ、障害発生時には早急に復旧させなければなりません。

このように、クラウドサービスを運用するにあたりサーバーに手を加えなければならない機会は沢山あり、場合によっては、サーバーの構成変更がアプリケーションの安定稼働に悪影響を与えることもあります。また、長年運用を続けているとサーバー更新履歴が積み重なっていくため、どのサーバーがどういった状態になっているのか把握するのが困難になってきてしまいます。

Aipo.com ではどういった仕組みで運用しているのかご紹介したいと思います。

Immutable Infrastructure とそのメリット

Immutable Infrastructure(イミュータブル・インフラストラクチャ)というキーワードをご存知でしょうか。「不変のインフラ」という意味になりますが、一度サーバーを構築したらその後はサーバーには手を加えない、といった仮想化やクラウドを基盤としたインフラの考え方です。一昨年頃から注目されてきました。(ただし、海外ではこのワードはあまり使われないそうです。)

Immutable Infrastructure では、サーバーはいつでも破棄できる状態にしておき、アプリケーションのアップデート時など、サーバーの変更が必要な際には既存のものを破棄して新しいものと入れ替える、といった運用スタイルとなります。

Aipo.com でも Immutable Infrastructure の考え方を取り入れています。

immutable_infractructure.png

メリットとしては、 

すべてのサーバーの状態が同じであることが保証される。

サーバーを構築した後は変更を加えないため、クラスタを組んでいる場合にすべてのサーバーの状態が同じであることが保証されます。サーバー一つだけ変更の適用が漏れていた、といったことは防ぐことができます。また、脆弱性の対応時にもセキュリティパッチを充てた構成と順次入れ替えていくことにより、迅速に反映をおこなうことができます。

アプリケーションやサーバー構成の切り戻しが容易にできる。

いつでも破棄ができる状態に保っているため、サーバー変更時に何か問題が発覚した際には、今度は新しい構成のものを破棄して、古い構成のものと入れ替えることにより、切り戻しが容易にできるようになります。

自律的な障害復旧が可能となる。

クラウド環境で複数のサーバーを運用していると、時おりサーバーホストやサーバー内部に起因する障害が発生することがあります。長期間続くものや、一瞬で修復するもの、断続的に発生するものなどさまざまです。いずれにおいていも、「サーバーの不良(疑い)が発見されたら、そのサーバーは破棄して新しいものと入れ替える」といった簡単なルールを定義しておくだけで、自律的な障害復旧ができるようになります。障害の要因については復旧後に調査を行えばよいのです。

スケーラビリティが実現できる。

Immutable Infrastructure が実現できていれば、サーバーの増設の自動化も同時に実現できているはずなので、サーバーのスケーラビリティを確保することは容易です。また、アクセスの少ない時間帯は減らす、CPU の負荷が高くなってきたら増やす、などのオートスケールについても容易ににできるようになります。

顧客のデータを守ることができる。

いつでもサーバーを破棄できる状態にしておく設計を受け入れることにより、顧客のデータの管理はアプリケーションとは切り離して行うことができるようになります。アプリケーションサーバーとは独立した環境で、バックアップ、バージョニング、ミラーリングなどデータを守るための機構を整備しておけば、サーバーの障害などで顧客のデータがロストしたり破損してしまうリスクは格段に減らすことができます。


ただし、良いことばかりでもなく、アプリケーション側に大きな「制約」を受け入れる必要があります。いつでも破棄できる状態に保つということは、すなわち、サーバーにデータを保持しておくことはできない(ステートレスな構成が要求される)、ということになります。Aipo.com のようにデータベースやファイルを多く取り扱うアプリケーションの場合はどのように実現すればよいのでしょうか。

Aipo.com での Immutable Infrastructure の実現方法

グループウェア「Aipo」は2008年3月にオープンソースとして公開をしました。当然、その頃はアプリケーションの設計としてクラウドを意識したものとはなっていませんでした。その後、2011年6月に AWS を採用したクラウドサービスとして「Aipo.com」の前身、「Aipo+」をリリースしています。このリリースに伴い、Aipo 自身のアーキテクチャの見直しが必要となりました。ただし、オープンソースとしては継続して提供していくことになるため、全く新しいシステムとして再構築するという選択肢はとらず、オープンソース版 Aipo に独自のクラウドモジュールを掛け合わせることにより構築できるようにしています。

そして、Aipo のクラウド対応を進める中、大きな出来事が起こりました。2011年4月11日、AWS において EBS (仮想インスタンスの外付け HDD のようなもの)の大規模障害が発生しました。長期間、サーバーのデータ部分にアクセスできなくなるといった、致命的な障害となるので、今後 AWS 利用者として、安定したサービスを提供するためにはどのような対策を講じるべきか課題が残りました。

この大規模障害も踏まえた上で、アーキテクチャを決めるにあたり、以下の2点を満たせるよう検討を進めてきました。

  • 顧客のデータを守るためにはどうすればよいか
  • 顧客に新しい価値を配信し続けるためにはどうすればよいか

まず大前提として、顧客のデータを守ること、そして、その上で利用価値を最大限に高めていく。そして、この課題を解決するための、唯一の設計方針として、

「顧客のデータはサーバー(インスタンス)に保存しない。インスタンスはいつでも破棄できるものとし、ゼロからすぐにセットアップできるようにする」

という結論に至りました。このルールをクラウドサービス初期からずっと続けています。

当時は、Immutable Infrastructure という言葉はなかったと思いますが、本質的には同じような考え方ですね。


では、具体的な構成を見てみましょう。オールインワンのインストールを前提としたオープンソース版のAipo、Immutable Infrastructure に基づいた Aipo.com、構成の違いは以下のようになります。

  オープンソース版Aipo Aipo.com
ミドルウェア サーバーにインストール・設定変更 AMI から起動後構成済
アプリケーション サーバー上のHDD に配備・上書き 起動時に自動的にS3から配備
セッション サーバー上のメモリに保存 ELB sticky session / ElastiCache に保存
データベース サーバー上の HDD に保存 RDS に保存
ファイル・メール サーバー上の HDD に保存 S3 に保存
ログ サーバー上の HDD に保存 CloudWatch Logs / S3 へ転送

このように Aipo.com の構成では AWS のサービスを活用してデータはサーバー上に保存しない、あるいは、破棄されても差し支えないデータのみ保存するようにしています。

最大の肝となる、ファイルデータの保存、共有については、分散ストレージや NFS、ミラーリングなど、サーバー同士が密に結合されてしまう構成については選択しませんでした。サーバーを破棄、入れ替えに難があるからです。比較的容易に実現できる選択肢が S3 でした。S3 があるから AWS を採用したと言っても過言ではありません。

また、オープンソース版のAipo側では、DI(Dependency Injection) のような仕組みを実装しておき、オープンソースとクラウドの構成を切り替えられるようにしています。そして、サーバーの設定変更が必要な場合は、設定変更済みの新しい AMI にアプリケーションをデプロイして、既存のインスタンスと入れ替えることにより Immutable を保っています。

これがオープンソース版AipoとクラウドのAipo.com を両立しながら、Immutable Infrastructure を実現している仕組みとなります。

まとめ

Immutable Infrastructure という考え方、そのメリットや実現方法について、Aipo.com の運用事例を元にご紹介いたしました。ポイントとしては、

  • Immutable Infrastructure とは、本質的には「破棄できるコンポーネント」ということ。
  • クラウドサービスを運営する上で多くの恩恵をうけることができる。
  • サーバー(インスタンス)にはデータを保存しないことを前提とする。
  • AWS の各種サービスを活用すると、実現への近道になる。

Immutable Infrastructure と聞いて、多くの方は Docker のようなコンテナを活用して実現するものとイメージをもたれているかもしれませんが、Aipo のようなレガシーなアークテクチャのアプリケーションであっても実現は可能ですので、参考にして頂ければと思います。

現在私たちの仲間を募集しています!

2015/02/06 13:00:00
別府