PR

オンプレミスで稼働していたシステムをパブリッククラウドに移行したいが、可用性やセキュリティが心配―。このように考えるユーザーは何に注意すべきか。Amazon Web Services(AWS)を例に、基幹系の基盤として活用する際に押さえておくべきポイントを解説する。

 読者のみなさんはAmazon Web Services(AWS)が登場したきっかけを、ご存知だろうか。2003年、米Amazon.comのインフラ管理を担当していたChris Pinkham氏とBenjamin Black氏が社内向けに書いたショートペーパーがその1つと言われている*1。ショートペーパーはAmazon.comのインフラストラクチャーの未来について記し、その内容は「完全に標準化、自動化され、ストレージのようなものは広範囲にわたってWebサービスとして利用される」というものだった。

 Amazon.comのCEO(最高経営責任者)であるJeff Bezos氏はこのショートペーパーを気に入り、その実現に向けてインフラストラクチャーを拡充。その結果、後にAmazon社内だけでなく、世界中で利用されるAWSへと進化した。

 そして今ではAWSは、大企業の基幹系システムのインフラとしても利用されるようになった。ユーザー企業はAWSを利用することで、サーバーの調達コストを抑えられ、大切な時間を真に価値ある仕事に割り当てることができるようになっている。

 ITエンジニアにとって強力な道具となるAWSだが、上手に活用できなければ宝の持ち腐れになってしまう。初めてAWSにアクセスした人の中には、あまりのサービス数の多さに圧倒される人も少なくない。そのためか「AWSを使うのは難しい」というイメージもあるようだ。

 しかし基本的な考え方が分かればAWSを基幹系システムで使うことは難しくない。「責任共有モデル」や「Design for failure」いったクラウド独自の考え方が分かれば、エンジニアにとって面白い世界が広がる。以下では、AWSを基幹系システムで利用するうえで、欠かせない考え方を紹介していく。

99.95%は「努力目標」

 オンプレミスで稼働していた基幹系システムをAWSに移行する際に、可用性や信頼性の確保は重要なポイントの1つになる。

 AWSの仮想マシンサービス「Elastic Compute Cloud(EC2)」の場合、サービスレベルアグリーメント(SLA)では「月間使用可能時間の割合が99.95%以上」というサービスコミットメントが明示してある。それを守れなかった場合には「次期の支払いに使える使用量の割引率」であるサービスクレジットも定義されている。

 しかしこのSLAはあくまでAWS側の「合理的な努力目標」であり、サービス品質を保証するものではない。そのため基幹系システムでのAWS利用に際して高い可用性を目指すには、利用者自身でシステム構成を工夫する必要が出てくる。構成で特に気を付けたいのが、基幹系システムでよく利用されるEC2と、AWSの利用には欠かせないネットワークだ。

「複数のAZ」で冗長化

 まずはAWSの基本的な構成をおさらいしよう。AWSはリソースを動かすリージョン(地域)を世界中から選択できる。各リージョンは、複数の「アベイラビリティーゾーン(AZ)」で構成されており、AZは1つ以上の独立したデータセンター(DC)から成っている。

 AWSを使ったシステムの信頼性を高めるには、「同じ役割を持つEC2を複数のAZに配置し、冗長構成にする」ことが基本的な考え方となる。加えて冗長構成を採った際に、クライアントから見て複数のAZに配置したEC2を「あたかも1つの接続先に見えるようにする」作業が必要になる。言い換えれば、複数のEC2インスタンスを何らかの方法で1つに束ねなければならない。代表的な方法がロードバランサーの利用と、ソフトウエアの利用だ。

 ロードバランサーを利用した冗長化は、複数のEC2の前段にロードバランサーを配置し、クライアントからロードバランサーの提供する接続先を指定する方法だ。AWSが提供する高可用性のロードバランサー「Elastic Load Balancing(ELB)」を利用できる(図1)。

図1●ロードバランサーを使った冗長構成の例
図1●ロードバランサーを使った冗長構成の例
[画像のクリックで拡大表示]

 ただし2017年10月時点で、ELBがサポートするのは、「レイヤー7(HTTP/HTTPS)」と「レイヤー4(TCP)」のみだ。UDP(User Datagram Protocol)など、他のプロトコルを使用する場合は、F5ネットワークスの「BIG-IP」などのサードパーティ製のロードバランサーを利用する必要がある。

 ここで注意したいのは、サードパーティ製のロードバランサーを利用する場合、ロードバランサーを導入して稼働させるEC2を別途、用意する必要があるということだ。信頼性を高めるためには、ロードバランサー自体の冗長化も検討する必要がある。

 ソフトウエアを利用してEC2の冗長化を実現する方法では、まずEC2インスタンスのOS上にクラスタリングソフトを導入し、クライアントからクラスタリングソフトが提供する代表IPアドレスに接続する(図2)。

図2●ソフトウエアを利用した冗長化構成の例
図2●ソフトウエアを利用した冗長化構成の例
[画像のクリックで拡大表示]

 クラスタリング用のサービスはAWSでは提供されていないため、NECの「CLUSTERPRO X」などAWSに対応したサードパーティのソフトウエアを利用することが前提になっている。

専用線接続を前提に

 EC2とともに信頼性を高めておきたいのがオンプレミス(自社)環境とAWSを結ぶネットワークだ。AWS上に構築したシステムへのアクセスは、VPNを含むインターネットを介したアクセスと、「Direct Connect(DX)」と呼ぶ専用線接続サービスを介したアクセスの2種類がある。

 基幹系システムをAWS上で構築する場合、オンプレミス環境で稼働するシステムとの連携が必要な場合が多いため、DXを利用するほうが、低遅延、広帯域のネットワークで接続することになり、信頼性の向上につながる。

設定もユーザーが責任を持つ

 基幹系システムをAWSで稼働させる際に信頼性や可用性とともに注意を払いたいのがセキュリティの確保である。AWSに限らずパブリッククラウドでは、DCの場所や内部のシステムの情報が原則公開されず、ブラックボックスになる。

 数年前までは「本当にクラウドを利用して安全なのか」「信頼性は担保されるのか」といった不安の声が挙がっていた。しかしクラウドが実現するセキュリティの高さに理解が進み、2017年に入ると「セキュリティを確保するためにクラウドの利用を検討する」といった企業も登場するなど、セキュリティへの不安は払拭されつつある。

 とはいえ、基幹系システムでAWSを利用する場合には基本的なセキュリティの考え方や注意事項を押さえておく必要があるのは変わりない。

 AWSがサーバーリソースなどの内部の詳細な仕組みについて一部の情報しか公開しなかったり、DCの場所を明らかにしなかったりするのは、AWSとユーザーの責任を明確に分ける「責任共有モデル」という考え方を採っているためだ。AWSを利用するうえでは、責任共有モデルを理解しておくことが非常に重要になる。

 責任共有モデルにおいて、AWSはDCやハードウエアの管理と運用に責任を持ち、ユーザーは仮想ネットワークやOS内部、そしてAWSの各種設定について管理と運用を行う責任があると定義している(図3)。

図3●「責任共有モデル」の概要
図3●「責任共有モデル」の概要
[画像のクリックで拡大表示]

 責任共有モデルに従って、AWS側の責任範囲についてはユーザーに情報を公開しない代わりにAWSでは第三者の認証や監査を経て、管理が正常に行われていることを提示している。責任共有モデルでは、ユーザーはオンプレミスと同様に、OSの管理機能やセキュリティソフトの利用を通じて、セキュリティを確保することになる。

セキュリティサービスは充実

 責任共有モデルに従うといっても、AWSは全てのセキュリティ管理をユーザー側に任せきりにするのではなく、セキュリティ確保のためのサービスを用意している。多くのサービスは基本的にはAWSが「提供しているだけ」であり、設定と管理はユーザーが責任を持って行う。

 EC2などのサービスでは、「セキュリティグループ」と呼ぶアクセス制御の機能を用意しており、これを利用してOS上ではなく、AWS側で接続元のIPとポート番号を制限できる(図4)。

図4●セキュリティグループの考え方
図4●セキュリティグループの考え方
[画像のクリックで拡大表示]

 ユーザー側でカスタマイズ可能なWAF(Webアプリケーションファイアウオール)の「AWS WAF」や、ユーザー側の設定が不要なDDoS(分散型サービス拒否攻撃)対策サービス「AWS Shield」といったサービスもある。

 最近ではセキュリティ分野でもAWSのパートナーやサードパーティ製品で、AWSに対応したサービスが増えつつある。トレンドマイクロのセキュリティソフト「Deep Security」は、AWSアカウントと連携してサーバーの一覧を管理できるだけでなく、負荷に応じてサーバーの台数を自動的に増減する「オートスケール」にも対応している。

設定ミスで全世界に公開

 責任共有モデルでは、「ユーザー自身が実施するAWSの設定についてもユーザーが責任を持つ必要がある」と定義しているのは前述の通りだ。セキュリティの観点から考えた場合、AWSの設定を間違えたまま利用してセキュリティインシデントが発生したとしても、「全てはユーザーの責任」という考え方になる。

 実際にユーザーの設定が誤っていたことが原因のセキュリティインシデントは発生している。

 最近ではストレージサービス「Simple Storage Service(S3)」で、ユーザーの設定が誤っていたために大規模な情報流失につながるという事件が発生した。ユーザーはS3にデータを保管する際に、権限設定を行う必要がある。S3のデフォルトの設定は、AWSアカウント内の限られたユーザーにのみアクセスを許可している。ところが今回の事件では権限設定を誤り、一般のユーザーからもアクセス可能な状態になっていたのだ。

 セキュリティグループの設定においても、特定のIPアドレスからのアクセスだけを許可しているつもりが、「全世界からのアクセスを許可してしまった」ということが少なくない。

 ちょうど本稿の執筆中にも、S3の設定ミスを狙った攻撃が報告された。一般公開されているS3に対して、マルウエアを仕込んだファイルをアップロードしておき、S3利用者に気付かれずにマルウエアをダウンロードさせるという手口だ。

監査とルール作りも重要に

 このような権限設定のミスでインシデントが発生した場合、全てはユーザーの責任になる。

 AWSでは「Identity and Access Management(IAM)」というサービスを利用して、ユーザーの作成や権限管理を行う。IAMではユーザーにAPIキーを払い出し、そのキーを利用してAWS内の操作を行わせることができる。

 この機能は大変便利な一方で、キーが流出することで様々なセキュリティインシデントの発生につながる。既にAWS内の重要なデータを盗まれたり、勝手にEC2を立ち上げられ暗号通貨のマイニングに利用されたり、といったケースが発生している。

 IAMユーザーの情報が漏洩した場合、AWS内部に甚大な被害が発生する可能性がある。防止するには、ユーザーに渡す権限を最小限に抑えたうえで、不要になったものは停止、あるいは削除するといった運用の徹底が欠かせない。

 AWSを安全に利用するためには、従来のオンプレミス環境と同様にネットワークやOSの管理を行うとともに、AWSの設定自体についても管理が求められる。

 「インフラストラクチャーであるAWSの設定の管理に責任を持つ」という考え方は、オンプレミス環境ではなじみがないユーザーが多いかもしれない。AWSの設定を適切に維持するためには、一度設定して終わりにするのではなく、明確なルール作りと定期的な監査が必要になることに注意しよう。

「システムは故障する」が前提

 信頼性や可用性を高め、セキュリティを確保したシステムをAWS上に構築しても、その後の運用をAWSに合わせて正しく設計・実装しなければ安定的にシステムを利用できない。AWSでは運用設計を考えるうえで「Design for failure」の考え方が重要になってくる。

 AWSの設計指針として「クラウドコンピューティングのアーキテクチャ:ベストプラクティス」というホワイトペーパーがある*2

 そこにいくつか記されている指針の中で、最も有名なのがDesign for failureだ。「システムは故障する可能性があるものだという前提を受け入れ、あらかじめ故障に備えた設計をする」という考え方である。

 簡単な例としては、「サーバーを1台のみで動作させるのではなく、複数台で冗長化する」というのがこの考え方に当たる。

 この考え方はオンプレミス環境でも当てはまるものの、AWSを利用する際にはより重要になる。AWSではオンプレミス環境に比べて冗長構成を安価に構築できるからだ。オンプレミス環境では、サーバーが高価で「冗長化したくてもできなかった」というケースもあった。AWSではこうした価格面のハードルは下がるため、冗長化が可能かどうかを検討することが欠かせなくなる。

マネージドサービスを取り入れる

 もう1つ、AWSを使ったシステムの運用を考える際に押さえておくべきポイントが「積極的にマネージドサービスを使うこと」だ。

 読者の皆さんがAWSを利用するきっかけは「コスト削減」「資産を持ちたくない」など様々だろう。ただし根っこにある本当の理由は、インフラストラクチャーやミドルウエアなどの運用管理を手放し、「開発などの本来の業務に集中したい」というものではないだろうか。

 そこで運用などの非機能要件の実現をAWSに任せて運用負荷を減らしていくことが「AWSらしい設計」となる。運用負荷軽減のため、積極的にマネージドサービスを利用していくことを検討しよう。

 マネージドサービスの代表例が、リレーショナルデータベースの「RDS(Relational Database Service)」だ。データベースのログ取得、バックアップやパッチの適用をAWSが用意した機能で実現できる。EC2の中にDBをインストールするのではなく、RDSを用いることで運用をAWSに任せられる。

サポートと計画メンテナンス

 日々のAWSの運用を考える際には、サポートサービスへの加入と計画メンテナンスを考慮することが欠かせない。

 AWSにはベーシック、開発者、ビジネス、エンタープライズの4種類のサポートプランがある*3

 プランごとにカスタマーサービスの対応時間や、緊急度/初回応答時間などの項目が記載されている。特に重要なのが「技術サポートへのアクセス」の項目だ。

 ビジネス以上のプランの場合、24時間年中無休で電子メールによる問い合わせを受け付けてもらえる。業務への影響が大きいシステムをAWS上で構築する場合には、ビジネス以上のサポートプランに加入しておこう。

 AWSを運用する際に、慣れておくべきなのが計画メンテナンスの発生だ。ユーザー側の都合でメンテナンスを実施できたオンプレミスとは考え方の転換が必要になる。

 AWSはEC2やRDSのインスタンスを搭載しているハードウエアを計画メンテナンスすることがある。メンテナンスはAWS側が実施するものであり、対象のインスタンスや時間といったユーザーに影響がある情報はAWSから電子メールで通知される。

 責任共有モデルの通り、メンテナンスはAWS側の責任となるためユーザー側が気にする必要はない。ただし、対象となるEC2やRDSのインスタンスがメンテナンスによって一時的に再起動されてしまうことに注意が必要になってくる。

 多くの場合、ユーザーが事前に対象インスタンスをstop/startすることで再起動を回避できる。回避方法もAWSから送られる電子メールに記載されている。

 Design for failureの考え方にのっとってシステムを設計していれば、EC2をstop/startさせる際にも業務を停止させることはない。業務に影響を与えないメンテナンスが可能になり、運用性が高まる。

責任共有モデルの運用に変える

 これまでオンプレミス環境のシステムを利用していたユーザーにとって、AWSを利用することはシステム構築の考え方を大きく変えることにつながる。

 責任共有モデルが示す通り、物理レイヤーの保守運用責任はAWSにあるので、ユーザー側は物理的なAWS基盤を意識する必要はない。ただしそれにもかかわらず、オンプレミス環境のシステムからAWSへ移行すると物理的な基盤が気になるのは当然の話だ。

 EC2で予期しない再起動があったとき、AWSのサポートにAWS基盤側での障害内容を問い合わせたくなるユーザーも多い。しかし、それはAWSを利用するうえでは、「全くのムダ」と言える(図5)。

図5●責任共有モデルと運用のパラダイムシフト
図5●責任共有モデルと運用のパラダイムシフト
[画像のクリックで拡大表示]

 一時的にAWSの基盤側で問題があったとしてもユーザー側は原因について何も感知できない。何もせずAWSに任せることが、AWSを利用するうえでの「賢いコストの考え方」となるのだ。

 AWSを利用した当初、「ハードウエア障害の詳細が分からない」「AWS側の都合でメンテナンスを実施する」といった運用を怖いと感じるかもしれない。しかし責任共有モデルのパラダイムを意識した運用に切り替えることが、AWSを上手に利用するコツになる。

*1
http://blog.b3k.us/2009/01/25/ec2-origins.html
*2
https://aws.amazon.com/jp/whitepapers/architecting-for-the-aws-cloud-best-practices/
*3
https://aws.amazon.com/jp/premiumsupport/compare-plans/
高田 知典(たかだ とものり)
サーバーワークス クラウドインテグレーション部 技術3課
高田 知典(たかだ とものり) 大学卒業後ユーザー企業、SIer、通信事業者でのシステム構築経験を経て、2015年よりサーバーワークスにてAWSでのシステム構築に従事。九州を中心に担当しており、事業拡大による福岡オフィス移転の際は引越番長として他のメンバーを取りまとめた。AWSの認定資格は今年「Advanced Networking - Specialty」に合格し現在6冠目。7冠となればさらにモテるのではと周りから期待されている。
高橋 大成(たかはし たいせい)
サーバーワークス マネージドサービス部
高橋 大成(たかはし たいせい) 2014年に新卒でサーバーワークス入社。今までAWSの設計構築、SaaS導入支援、クラウドのセキュリティコンサルティングに従事。AWS案件をこなしながら顧客視点でより良いSaaSサービスを使ってもらえるための提案も進んで実施しており、そこから得た知識で「シナリオで学ぶパブリッククラウド Amazon Web Services 設計&開発ガイド(日経BP社)」を執筆。趣味はブラジリアン柔術。
坂井田 保彦(さかいだ やすひこ)
サーバーワークス ソリューションアーキテクト
坂井田 保彦(さかいだ やすひこ) 2013年サーバーワークス入社。エンジニア、プロジェクトマネジャーを経験した後、関連会社のクラウド専業MSPであるスカイ365へ出向。東京から北海道へ転勤となり、大好きなスープカレーを堪能する。2016年にサーバーワークスに戻り、現在は多岐にわたるAWSインテグレーション業務に携わった経験を生かし、ソリューションアーキテクトとしてお客様のAWS導入を支援する活動をしている。