Panasonic ecoideasnet に見る クラウド最新活用ノウハウ

第3回 戦略的Webマーケティングセミナー コストだけでない Amazon Web Services のメリット Panasonic ecoideasnet に見る クラウド最新活用ノウハウ 2010年3月2日 小島 英揮 Amazon Data Services Japan株式会社 マーケティングマネージャー 青木 誠 後藤 和貴 株式会社ビジネス・アーキテクツ 取締役、シニア・アートディレクター テクニカルディレクター

• http://gihyo.jp/event/2010/webmk03

本日のアジェンダ 2 Amazon Web Services™ (AWS) について プロジェクトの目的 ecoideasnetのご紹介 プロジェクト要件 施策例 Amazon Web Services 選択の理由 Amazon Web Services による変化 Amazon Web Services で変化しなかったこと まとめ

Amazon Web Services™ (AWS) について

AWSの特徴 アマゾンの高度なEコマ―スサイトの運用ノウハウとテクノロジーを IaaSなクラウドとして提供 SLA（稼働時間：99.95％）を提示 ⇒運用に24時間人を張り付ける必要なし 完全従量制（初期費用無し）+ 低コストで、CPU、ストレージ、DB, 及び各種サービスを提供 ⇒キャッシュフロー経営に効果大 Windows、Linux、OpenSolarisの仮想化環境を提供 ⇒既存のアプリケーションの移植性が高い（技術的なジャンプ少） DB、ストリーミング、オートスケールの機能等、より運用を簡単に するためのサービスを順次追加 ⇒サーバサイドのインストールや運用負担を軽減

AWS の目標: 工数の配分改善 30% 従来型の ITインフラ AWS利用による クラウドインフラ 70% Your Business Managing All of the “Heavy Lifting” More Time to Focus on Your Business Configuring Your Cloud Assets 70% 30%

AWS のポジション 既存資産、技術との親和性と、クラウドのメリットを兼ね 備えたIaaS 技術の親和性 Apps Apps Apps Apps SaaS MW MW MW OS 仮想OS 仮想OS PaaS ・・・・・・ 既存社内環境 / データセンター ・・・・・・ PaaS / SaaS クラウド的調達と スケーラビリティ

AWSが提供するサービス AWSで提供されるサービス群 Isolated Networks Monitoring Management Tools Amazon CloudWatch AWS Management Console AWS Toolkit for Eclipse Parallel Processing Amazon Elastic MapReduce Amazon Virtual Private Cloud Content Delivery Messaging Payments Amazon CloudFront Amazon CloudFront Streamaing Amazon Simple Queue Service (SQS) Amazon Flexible Payments Service (FPS) Compute Storage Amazon Elastic Compute Cloud (EC2) Amazon Simple Storage Service (S3) -Elastic Load Balancing -Auto Scaling -AWS Import/Export On-Demand Workforce Amazon Mechanical Turk Database Amazon RDS Amazon SimpleDB

Amazon S3 クラウド上のスケーラブルなデータストレージ 高い信頼性と永続性 従量制課金（Pay-as-you-go） :  使用するディスク容量とデータ流量での課金 CloudFrontとの組み合わせで高速なCDNを構築  CloudFrontのEdgeサーバは東京にも有り CloudFront Streamingとの組み合わせでオンデマンド ストリーミングにも対応  Adobe Flash Media Serverをビルトイン

Amazon EC2 オンデマンドで必要なCPUパワーを提供  数分で新しくサーバ（＝インスタンス）を起動  スケールアップ、ダウンも迅速に実現 従量課金制（Pay-as-you-go):  インスタンスの時間貸し＋データ流量 主な特徴:  主要なOS、Web、アプリケーションプラットフォームをサポート  Elastic IPs (固定IP)による運用の柔軟性  Elastic Block Store(EBS)による永続的なデータ利用  ロードバランサー（Elastic Load Balancing） + モニタリング (CloudWatch) + オートス ケールにより、負荷分散、サーバの自動増減等の運用自動化が可能  Availability Zone（データセンター）をまたがった冗長構成が可能 2010年はアジア地域に2か所データセンター拡張

Amazon EC2で選択できる構成 Standard High-CPU High-Memory Small Large Extra Large Medium Extra Large Double Extra Large Quadruple Extra Large Bits 32 64 64 32 64 64 64 RAM 1.7 GB 7.5 GB 15 GB 1.7 GB 7 GB 34.2 GB 68.4 GB Disk 160 GB 850 GB 1690 GB 350 GB 1690 GB 850 GB 1690 GB EC2 Compute Units 1 4 8 5 20 13 26 Cores 1 2 4 2 8 4 8 Yes Yes Yes Yes Yes Yes Yes Firewall 1 3 Spot Pricing (USD) Linux Per Hour $0.085 $0.34 $0.68 $0.17 $0.68 $1.20 $2.40 Windows Anon $0.12 $0.48 $0.96 $0.29 $1.16 $1.44 $2.88 $0.085 x 24h x 30Days = $61.2(約¥5,500) $0.68 x 24h x 30Days = $489.2(約¥44,000) $2.4 x 24h x 30Days = $1,728(約¥155,500)

AWSのデータセンター構成 US East Region Zone A Zone B Zone D Zone C EU West Region Zone A Zone B US West Region Zone A Zone B Region (地域) 及び Availability Zoneを選択可能 RegionとAvailability Zoneの組み合わせた運用可能  高い耐障害性  2010年にアジアにリージョンを2か所追加

AWSが解決する利用シーン 実際の トラフィック 需要予測 重要予測の難しいアプリケーション 「ハネる」キャンペーンサイト、 ソーシャルアプリ、ゲームサイト 定期的に大量データ処理を必要とする業務 期間限定＋需要予測の難しい キャンペーン等

プロジェクトの目的

目指したこと パナソニックに強い興味は無いが、 エコに対して興味がある世界中のステー クホルダーとのコミュニケーションを目的 とした「グローバル環境コミュニケーション プラットフォーム」を構築する。 14

ecoideasnet のご紹介

のご紹介 ecoideasnet 16 サイトコンセプト 暮らしを輝かせる“ideas”の創造を通じて、 明日の Lifestyle を提案するパナソニック が、最新の eco ideas や eco lifestyle を 世界中から集め共有する「場」。 http://eco-ideas.net

• http://eco-ideas.net

のご紹介 ecoideasnet 17

のご紹介 ecoideasnet 18

のご紹介 ecoideasnet 19

プロジェクト要件 ① ブランディング ② コミュニケーション ③ 連動、支援、誘導 ④ 運用、拡張

プロジェクト要件① グローバルにおける 環境ブランディングの強化  グローバルに情報を配信するプラットフォーム。  立ち上げ時は欧州と北米を主たるターゲットとし て捉え、英語をベースに情報を提供する。  将来的に多言語対応も視野に入れた設計。  次世代の企業コミュニケーションの可能性を探る 半ば実験的な側面もある。 21  各国での通信環境やルーティングなどによる通 信速度のストレスを軽減。

プロジェクト要件② ソーシャルネットワークを基 盤としたエンドユーザーとの コミュニケーション  ソーシャルネットワークを通じた、双方向のコミュ ニケーションを形成し、強固なブランド基盤の醸 成を目指す。  既存サービスやネットワークインフラを最大限に 活用して、ユーザとの接点を増やす。  個人情報を保持せずに、ソーシャルネットワーク と連携し利用者の参加実績などを記録。 22

プロジェクト要件③ 自社の環境活動との連動、 マーケティング支援、 各国サイトへの誘導  社内各部門の環境コミュニケーションにおける ウェブのプレゼンスの高まりを受け、総合的な環 境コミュニケーションの受け皿を提供する。  各国に対して直接的・間接的な販売支援となる ようなブランディング施策を行い、各国のサイト へ誘導する。 23

プロジェクト要件④ スモールスタート、 継続運用、随時拡張  一過性のものではなく継続して運用する。  運営事務局・編集部の運用は日本で行う。  小さく生んで大きく育てられるように、スモールス タートから成長させていく計画。  初期投資の負担が少なく拡張性が高い柔軟な システムが必要。 24

施策例 プロジェクト要件に対して行ってきた 施策のいくつかを紹介します

施策例① Facebook(Facebook Connect), Twitter(OAuth), Google(OpenID) を利用したアカウント連携  アカウント連携をすることにより、利用者の登録 情報（個人情報相当分）を保持せずに、利用者 毎に実績などの情報を記録・管理することが可 能になった。  ユーザ管理機能の構築を最小限に抑え、開発 効率を高めることが可能に。 26  連携先のユーザネットワークへの波及効果を 狙った仕組みを実装。

施策例② 既存サービスとのマッシュ アップによるサイト構築  コンテンツ配信のインフラは、既存のWebサービ スを積極的に利用。（動画はYouTube）  アカウント連携したFacebookのファンページや Twitterのつぶやきなどを使った、“出先”での運 営側からのコミュニケーションを開始。 27

施策例③ AWSを選択： セキュリティリスクを回避  ウエブサービスとの連携を行うためのシステム構 築は、企業の自社ネットワークへ接続するリスク を回避する必要があり、外部サーバでの構築が 必要。 28

施策例④ AWSを選択： インフラへの投資とシステム 開発の効率化  ハードウエアインフラの構築に必要な時間とコス トを押さえ、システム構築のみに開発資源を投入 することが出来た。  初期投資を抑えながら信頼度の高いインフラを 利用したシステム構築を実現。 29

施策例⑤ AWSを選択： グローバル展開における 課題への対応  当初は通信速度にストレスを感じていたため、更 新性が低く利用頻度の高い共通リソースデータ や一部の動画などを、AWSのCloudFrontを 使って配信することにより、日本を含む各国での 通信速度によるストレスを軽減した。  サービスの組み込みの容易さ  検討～設計～実施まで数日間で対応 30

Amazon Web Services 選択の理由 プロジェクト要件 AWSの特長 リスク 31

Amazon Web Services 選択の理由 プロジェクト要件  グローバルに情報を配信するプラットフォーム。  データセンター拠点は日本ではなく、むしろ海外  開始時北米、ヨーロッパ。それ以外の各国への予定されている。  スモールスタート、継続運用、随時拡張  サーバー環境を最小構成にしながら、将来拡張できるサービス であることが求められる 32  サービス拡張時にもその要求を阻害しないスピード、構成変更 の容易さ、経済性が必要 ◆ 実際にCDN追加をリリース直前に実施

Amazon Web Services 選択の理由 33 AWSの特長  選択可能なデータセンター拠点  北米東海岸、北米西海岸、ヨーロッパ  CDN(CloudFront)は日本含め14箇所

Amazon Web Services 選択の理由 AWSの特長 Amazon EC2, Amazon Elastic MapReduce Amazon S3, Amazon SimpleDB North America and Europe Coming soon: Singapore 34 Amazon CloudFront Ashburn, VA / Dallas, TX / Los Angeles, CA / Miami, FL / Newark, NJ / Palo Alto, CA / Seattle, WA / St. Louis, MO / Amsterdam / Dublin / Frankfurt / London / Hong Kong / Tokyo

Amazon Web Services 選択の理由 AWSの特長  拡張性と可用性  一部に障害が発生しても保存されたイメージですぐに復旧可能  Amazon の信頼性  Pay as you use で必要なときに必要なだけ迅速にサービス追加 できる 35 出典: 米国RightScale社 (http://rightscale.com/)

Amazon Web Services 選択の理由 AWSの特長  サーバー管理が容易、ツールの選択肢  コマンドラインツール  Management Console 管理画面  クラウドコントロールサービス  APIを利用して独自に組み込むことも可能 36

Amazon Web Services 選択の理由 AWSの特長  バックアップ手法・スナップショット  OSイメージまるごと保存も可能  バックアップ処理時間は非常に短い  カスタムイメージ  ミドルウェア導入済み、アプリケーション導入済みのイメージ  同じイメージを使って同時に追加開発ができる  大きな構成変更、サービス追加が可能に 37  公開直前にCDN追加（検討～設計～実施まで数日間）

Amazon Web Services 選択の理由 リスク  ウェブサイト実装という面で既存のやり方と比べ て生じたリスクは無い  まだまだ事例が少ないため説得が難しい側面も  クライアント担当者以外の関係者  予算化および運用契約では少し注意が必要  基本従量課金のため予算計画の見通しが難しい 38  費用が完全に確定するのは月末  請求書は発行されずクレジットカードによる請求のみ

Amazon Web Services による変化 プロジェクト計画 プロジェクト体制 ネットワーク設計、サーバー設計 本番環境・開発環境 39

Amazon Web Services による変化 プロジェクト計画  ハードウェアやデータセンターなどインフラに関 わるものは通常かなり早い段階で確定し発注し なければならない  AWS導入前提になると、発注から調達完了まで 劇的に短くなるので計画の建て方が変わる  初期構築フェーズでの考え方  追加・変更時のスピード 40

Amazon Web Services による変化 プロジェクト計画 AWS導入前 企画 （要件定義） 設計 ▲発注 開発 テスト ▲調達 ▲リリース AWS導入後 企画 （要件定義） 41 設計 開発 ▲調達 テスト ▲リリース

Amazon Web Services による変化 プロジェクト計画 AWS導入前 企画 （要件定義） 設計 開発 ▲発注 テスト ▲調達 ▲リリース AWS導入後 企画（要件定義） 設計 開発 テスト 企画→検証→設計→実装 42 企画→検証→設計→実装 企画→検証→設計→実装 ▲調達 ▲リリース

Amazon Web Services による変化 43 プロジェクト体制  比較的小さな体制で設計・実装  自分たちでコントロールしやすく  結果として、心理的障壁・物理的な問題が軽減 クライアント 担当者 プロジェクト リーダー クライアント 担当者 プロジェクト リーダー クライアント IT担当 システム PM クライアント IT担当 システム PM インフラ 担当 データ ハードウェア ソフトウェア センター ベンダー ベンダー ベンダー 開発 担当 AWS • データセンター • ハードウェア • ソフトウェア 開発 担当

Amazon Web Services による変化 ネットワーク設計・サーバー 設計  早い段階で確定させる必要があり、かつ稼働し 始めると変更しづらいインフラ関連の設計が実 装直前まで待てる  データセンター、サーバー構成  ファイアウォール、ロードバランサー、OS/ミドルウェア  バックアップ、メンテナンス作業 44  一旦稼働させても変更・やり直しがいくらでも可 能

Amazon Web Services による変化 本番環境・開発環境  本番環境・開発環境の差が無くなる  OS・ミドルウェアインストール、設定済みのイメージを保存し、別 のインスタンスで起動  障害調査時の再現環境も直前のインスタンスイメージをコピーし て利用  開発環境から本番環境へのリリースは、開発時に準備したリリー ス用のインスタンスに差し替え、もしくは起動イメージの切り替え 45

Amazon Web Services で変化しなかったこと サーバー構成・アプリケーション構成 開発スタイル 46

Amazon Web Services で変化しなかったこと 47 サーバー構成・アプリケー ション構成 サーバーが完全仮想化されていること、またさまざ まはOSやカスタムイメージが存在していることから、 何の制約もなく構成の検討ができた。

Amazon Web Services で変化しなかったこと Internet Load Balancer www1 (Web + DB) 負荷対策と冗 長化のため2 台構成 mounted volume 永続的なデータ 保存用ディスク領 域 バックアップデー タ保存用ディスク 領域 www2 (Web + DB) exported volume mounted volume EC2 コンテンツを NFSで共有 External Disk Snapshot CloudFront edge server 48 Elastic Load Balancing 高速にコンテンツ 配信 Elastic Block Store CDN content CloudFront edge server Internet CloudFront配 信用ディスク領 域 CloudFront edge server S3 CloudFront

Amazon Web Services で変化しなかったこと 開発スタイル  OSから選択可能なので、開発環境（OS/ミドル ウェア/フレームワーク/開発言語）への影響が一 切ない  逆に環境準備が劇的に変化  カスタマイズしたオリジナルのOS環境（AMI）を作成  特定のフレームワーク導入済みのイメージ、自社開発フレーム ワーク導入済みイメージを数分で準備可能 49

これから…

これから・ ・ ・ AWSへの要望 今後取り組みたいこと  DNSホスティング  基本的にCNAMEベースでの連携なので出来ないことがある  例: eco-ideas.net(ホスト名無し)で永続的なロードバランシング  フェールオーバー構成  稼働率と信頼制をさらにあげるためにHeartBeat構成を行い、 主要な機能は切り替え可能に（DB・アプリケーションサーバー）  CloudFront ストリーミング 51  比較的ファイズの大きい動画をストリーミング再生にすることでコ ンテンツ再生のパフォーマンスを改善

まとめ 52

まとめ プロジェクトの視点から  インフラなどの要件決定（時間的・物理的）の制 限から解放され、目的や成果など様々な条件を 考慮した上で意思決定することが可能に。  ハードウエアの納品や設定、ネットワーク構築な ど、プロジェクト設計上遅延やコスト増大につな がるリスクが極小に。  インフラが資産ではなく従量型サービスになる。 53

まとめ 実装技術の視点から  AWS導入による変化はインフラの考え方の変化 であって、ウェブサイト実装手法の変化は全くな い。  サーバー構築は論理的な設計でほぼ完了する ため、物理的な課題(場所、容積、電源）から解 放され、本来やりたいことに集中できる。 54  完全仮想化されたAWSに乗せることで、他では 得られない拡張性、可用性、運用手法を得るこ とができる。

ありがとうございました 小島 英揮 Amazon Data Services Japan株式会社 マーケティングマネージャー Phone: 03-4288-4221 e-mail: [email protected] 青木 誠 株式会社ビジネス・アーキテクツ 取締役、シニア・アートディレクター Phone: 03-3431-2511 e-mail: [email protected] 55 後藤 和貴 テクニカルディレクター web: www.aws-plus.com e-mail: [email protected]