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

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

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

Amazon Web Services™ (AWS) について

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

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

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

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

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 Quadruple Extra Large 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 1 4 8 5 20 1 13 26 Units 3 Cores 1 2 4 2 8 4 8 Firewall Yes Yes Yes Yes Yes Yes Yes Spot Pricing (USD) Linux $0.085 $0.34 $0.68 $0.17 $0.68 $1.20 $2.40 Per Hour Windows $0.12 $0.48 $0.96 $0.29 $1.16 $1.44 $2.88 Anon $0.085 x 24h x 30Days $0.68 x 24h x 30Days $2.4 x 24h x 30Days = $61.2(約¥5,500) = $489.2(約¥44,000) = $1,728(約¥155,500)

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

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

プロジェクトの目的

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

ecoideasnet のご紹介

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

17 ecoideasnet のご紹介

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

プロジグローバルにおけるェクト環境ブランディングの強化要件 ①  グローバルに情報を配信するプラットフォーム。  立ち上げ時は欧州と北米を主たるターゲットとして捉え、英語をベースに情報を提供する。  将来的に多言語対応も視野に入れた設計。  次世代の企業コミュニケーションの可能性を探る半ば実験的な側面もある。  各国での通信環境やルーティングなどによる通 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 AWSの特長理由  選択可能なデータセンター拠点  北米東海岸、北米西海岸、ヨーロッパ  CDN(CloudFront)は日本含め14箇所 33

選択の Amazon Web Services AWSの特長理由 Amazon EC2, Amazon Elastic MapReduce Amazon S3, Amazon SimpleDB North America and Europe Coming soon: Singapore Amazon CloudFront Ashburn, VA / Dallas, TX / 34 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 プロジェクト体制変化  比較的小さな体制で設計・実装  自分たちでコントロールしやすく  結果として、心理的障壁・物理的な問題が軽減クライアントプロジェクトクライアントプロジェクト担当者リーダー担当者リーダークライアントシステムクライアントシステム IT担当 PM IT担当 PM インフラ開発開発 AWS 担当担当担当 43 • データセンター • ハードウェア • ソフトウェアデータハードウェアソフトウェアセンターベンダーベンダーベンダー

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

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

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

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

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

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

これから…

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

まとめ 52

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

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

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

http://5net.com	159
http://www.aws-plus.com	48
http://www.cloudpack.jp	14
http://www.slideshare.net	12
http://cptl.corp.yahoo.co.jp	11
http://jisi.dreamblog.jp	10
http://localhost:81	6
http://www.itg.hitachi.co.jp	3
http://192.168.3.181:81	1

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

by Kazutaka Goto on Mar 03, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 264

Statistics