AWSを大規模活用する上で絶対に必要な「リファレンスアーキテクチャ」とは何か

今では数百万を超えるユーザーがいるAmazon Web Services。日本国内では10万を超えるユーザーがいると言われています。その数は今後も増加傾向にあり、エンタープライズ企業のシステムも、AWSでシステム化を検討する企業が増えてきました。
しかし、AWSの利用規模が拡大するにつれ、想定していないコストの肥大化や運用負荷を招いてしまうケースがあることもわかってきました。
そんな状況に陥らないためにも、テラスカイは、AWSを大規模に利用していくには、AWS利用の標準化・方針策定が必要だと考えます。本記事では、なぜ標準化・方針策定が必要なのか、標準化・方針策定とは具体的にはどういうことなのか、についてご紹介したいと思います。

図1が示す通り、現在、既に多くの企業がクラウドサービスを利用しており、今後もその利用規模は増加傾向にあります。さらに、IT予算増加の理由/用途（図3）に注目してみると、SoEに意欲的な企業が増えてきていることが分かります。（いわゆる守りのIT項目から、攻めのIT項目に推移していることから推測できます。）

SoEとは、Systems of Engagementの略で、「繋がりのシステム」を意味しています。「繋がりのシステム」とは、企業と顧客との接点を結ぶITシステムのことです。具体的には、企業が提供する、自社製品の情報を盛り込んだゲームやポイントの貯まるアプリケーションなどがその一例として該当します。昨今、このSoEへの投資を積極的に行い、顧客との接点をより強固にし、ビジネス収益に結びつけていこうと取り組む企業が増えてきています。

こうした傾向の背景には、クラウドサービスの利用により、IT部門がハードウェア機器などの調達、運用管理の手間から大幅に解放されたということがあるでしょう。「システムを止めない」「障害を起こさない」といったことに頭がいっぱいだったIT部門の担当者たちが、現在、社内のユーザー部門と共に「ITを活用して新しいビジネスサービスをどうつくるか」を考案したり、「新しい技術の選択」を提言するようになるなど、その姿勢は変わりつつあります。

このように、顧客接点を強化するためのITへの投資意欲が高まるなか、クラウドの利用、特にクラウドベンダーの中でも高いシェアを誇るAWSの利用は増加していくものと思われます。そしてこれを機に、併せて社内ITシステムのクラウド化(AWS化）を推し進め、オンプレミス型システムからの脱却を考える企業も多いようです。

一方で、AWSを既に多く利用している企業のなかには、クラウドの特性を活かしきれておらず、無駄なコストが発生してしまっている企業が多いことも分かってきました。こうした企業の多くは、業務システムごとに開発ベンダーがバラバラで、AWS利用に関する方針や基準が統一されておらず、AWS上にシステムが乱立しているという共通点があります。

小規模な利用のうちは、こうした基準のないシステムでも大きな問題にはなりません。しかし、その利用規模が大きくなればなるほど、ボトルネックは無視できないものとなり、本来期待されるコストやセキュリティを担保したITシステムの構築・運用が困難になってしまいます。ここからは、大規模なAWSシステムの利用で直面しがちな３つのボトルネックについてお話したいと思います。

AWSは、個々の機能がインスタンスごとに細かく分かれております。必要な機能（サービス）を組み合わせる形（オーダーメイド）でシステムを構築していきます。しかし、社内で統一された利用方針がなく、AWSを利用している場合、共通して使えるはずのサービス構成もゼロベースで作ることになってしまい、イニシャルコストが上昇してしまいます。こうした機能に対し、使用期間中は余分なランニングコストが発生し、最適化できるはずのコストがかさんでいるケースがあります。

AWSの利用で、サーバーやストレージ、ネットワーク機器といったハードウェアの調達時間やその検討に伴う労力は削減されました。しかし、クラウドサービスといえどサーバーを増やせば、その分の運用管理の負荷は増加します。クラウドにより気軽にシステムを構築できるようになってきたからこそ、増加するサーバー群に担当者が疲弊してしまうケースがあります。

AWSが提唱する「責任共有モデル」では、データセンターやハードウェアなどインフラ部分の責任はAWS、OS、アプリケーション、データの運用については顧客の責任と定義されています。こうした点を考慮した上で、オンプレとは違う運用の自動化や可視化といった効率化を図る必要があります。

共通のセキュリティ構築に関する基準がなく、業務システムごとに独自の基準でAWSの利用をすすめた結果、実は、会社が認めるレベルでのセキュリティ基準を満たしていなかったという話も実は珍しくありません。セキュリティ基盤の共通化やAWSが提供するサービスを上手く活用したセキュリティ強化を業務システムの特性に応じて行う必要があります。


参考ーーーーーーーーーーーーーーーーー
過去にはこのような事故もありました。

『Amazon S3の設定ミスにより、アメリカ国民1億2千万件の世帯情報が公開されていた』
引用サイトURL:https://news.yahoo.co.jp/byline/ohmototakashi/20171221-00079554/


『相次ぐAmazon S3の設定ミスによる情報漏えい事故』
引用サイトURL:https://news.yahoo.co.jp/byline/ohmototakashi/20171106-00077827

ーーーーーーーーーーーーーーーーーーー

このようなボトルネックを招くことなく、クラウドサービスのメリットを失わずにSoEに取り組んでいくためには、AWSの利用方針を全社で統一する必要があります。

具体的には、AWS上で構築する場合のインフラ構成をいくつかのパターンに分け、カタログ化することです。その際、AWSならではのセキュリティのポイントや運用管理項目をきちんと盛り込むことが重要です。そうした方針を、リファレンスアーキテクチャとして文書化し、社内全体で共有しましょう。

リファレンスアーキテクチャを共有するメリットは、IT担当者が最適な構成を組めるようになることです。構成に悩むこともなくなるので、スピーディーな構築が可能になります。SIベンダーに依頼する際、ベンダーがAWSに精通していなくても、最適な構成で依頼することができるようになります。

リファレンスアーキテクチャに、セキュリティを考慮した設計ポイントを標準的に盛り込んでおくことで、誰でも一定の安全性を保った構築が可能になります。さらに、運用の自動化や可視化に関する実現方式をカタログに標準的に盛り込んでおけば、バラバラにならない、効率の良い運用を実現することができます。

＜リファレンスアーキテクチャのメリット＞
・統一した基準でのシステム構成が可能
・システム構築スピードの向上
・セキュリティリスクの低減
・運用業務の標準化、効率化

”大規模”の目安としては、約50インスタンス以上を想定しています。移行対象としての多くは200インスタンス、或いは300インスタンス以上のケースで有効です。また、特に複数の事業部門やグループ企業を跨ってAWSを利用されていたり、複数の開発ベンダーにシステム構築を依頼している場合なども、リファレンスアーキテクチャの策定を視野にいれることを強くお勧めします。

＜こんな方には標準化をおすすめします＞
・全社的にAWSの利用を検討している
・複数部門、複数企業を跨いで利用している
・環境構築のスピードを向上させたい
・セキュリティを統一したい
・運用を標準化したい

リファレンスアーキテクチャは、AWSに精通した専門家による作成が理想です。
AWSならではの設計ポイントやセキュリティの概念に精通していなければ、一定の安全性を保持した設計が難しくなってしまいます。
テラスカイでは、豊富な構築経験を持つAWS認定資格保有エンジニアがお客様のシステム状況を十分にヒアリングした上で、AWS特有のポイントを盛り込んだ最適なリファレンススアーキテクチャを作成します。