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

  • View
    4.681

  • Download
    1

  • Category

    Business

Preview:

DESCRIPTION

2010年3月2日に行われた技術評論社主催のセミナーで話した「─コストだけでないAmazon Web Servicesのメリット─ Panasonic ecoideasnetに見るクラウド最新活用ノウハウ」の資料です。

Citation preview

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

コストだけでない Amazon Web Services のメリット

小島英揮Amazon Data Services Japan株式会社

マーケティングマネージャー

青木誠株式会社ビジネス・アーキテクツ

取締役、シニア・アートディレクター

後藤和貴テクニカルディレクター

第3回戦略的Webマーケティングセミナー

2010年3月2日

2

本日のアジェンダ

Amazon Web Services™ (AWS) について

プロジェクトの目的

ecoideasnetのご紹介

プロジェクト要件

施策例

Amazon Web Services 選択の理由

Amazon Web Services による変化

Amazon Web Services で変化しなかったこと

まとめ

Amazon Web Services™ (AWS)について

アマゾンの高度なEコマ―スサイトの運用ノウハウとテクノロジーを

IaaSなクラウドとして提供

SLA(稼働時間:99.95%)を提示

⇒運用に24時間人を張り付ける必要なし

完全従量制(初期費用無し)+ 低コストで、CPU、ストレージ、DB,

及び各種サービスを提供

⇒キャッシュフロー経営に効果大

Windows、Linux、OpenSolarisの仮想化環境を提供

⇒既存のアプリケーションの移植性が高い(技術的なジャンプ少)

DB、ストリーミング、オートスケールの機能等、より運用を簡単に

するためのサービスを順次追加

⇒サーバサイドのインストールや運用負担を軽減

AWSの特徴

AWS の目標: 工数の配分改善

AWS利用によるクラウドインフラ

YourBusiness

More Time to Focus onYour Business

Managing All of the “Heavy Lifting”

Configuring Your Cloud

Assets

70%

30%70%

従来型のITインフラ

30%

AWS のポジション

技術の親和性

OS

MW

Apps

仮想OS

MW

Apps

仮想OS

MW

Apps

・・・・・・

PaaS

・・・・・・

SaaS

Apps

クラウド的調達とスケーラビリティ

PaaS / SaaS 既存社内環境 / データセンター

既存資産、技術との親和性と、クラウドのメリットを兼ね備えたIaaS

AWSが提供するサービス

ComputeAmazon Elastic Compute

Cloud (EC2)-Elastic Load Balancing

-Auto Scaling

StorageAmazon Simple Storage

Service (S3)-AWS Import/Export

AWSで提供されるサービス群

Content DeliveryAmazon CloudFrontAmazon CloudFront

Streamaing

MessagingAmazon Simple Queue Service

(SQS)

PaymentsAmazon Flexible

Payments Service (FPS)

On-Demand Workforce

Amazon Mechanical Turk

Parallel Processing

Amazon Elastic MapReduce

MonitoringAmazon CloudWatch

DatabaseAmazon RDS

Amazon SimpleDB

ManagementAWS Management Console

ToolsAWS Toolkit for Eclipse

Isolated NetworksAmazon Virtual Private

Cloud

クラウド上のスケーラブルなデータストレージ

高い信頼性と永続性

従量制課金(Pay-as-you-go) : 使用するディスク容量とデータ流量での課金

CloudFrontとの組み合わせで高速なCDNを構築 CloudFrontのEdgeサーバは東京にも有り

CloudFront Streamingとの組み合わせでオンデマンド

ストリーミングにも対応 Adobe Flash Media Serverをビルトイン

Amazon S3

オンデマンドで必要な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-MemorySmall Large Extra Large Medium Extra Large Double Extra

LargeQuadruple 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

13 26

Cores 1 2 4 2 8 4 8

Firewall Yes Yes Yes Yes Yes Yes Yes

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)

Amazon EC2で選択できる構成

US East Region

Zone A

Zone B

Zone C

Zone D

US West Region

Zone A

Zone B

EU West Region

Zone A

Zone B

Region (地域) 及び Availability Zoneを選択可能RegionとAvailability Zoneの組み合わせた運用可能高い耐障害性 2010年にアジアにリージョンを2か所追加

AWSのデータセンター構成

AWSが解決する利用シーン

重要予測の難しいアプリケーション 定期的に大量データ処理を必要とする業務

「ハネる」キャンペーンサイト、ソーシャルアプリ、ゲームサイト

期間限定+需要予測の難しいキャンペーン等

需要予測

実際のトラフィック

プロジェクトの目的

14

目指したこと

パナソニックに強い興味は無いが、

エコに対して興味がある世界中のステー

クホルダーとのコミュニケーションを目的

とした「グローバル環境コミュニケーション

プラットフォーム」を構築する。

ecoideasnet のご紹介

16

サイトコンセプト

暮らしを輝かせる“ideas”の創造を通じて、

明日の Lifestyle を提案するパナソニック

が、最新の eco ideas や eco lifestyle を世界中から集め共有する「場」。

http://eco-ideas.net

ecoideasnet

のご紹介

17

ecoideasnet

のご紹介

18

ecoideasnet

のご紹介

19

ecoideasnet

のご紹介

プロジェクト要件①ブランディング

②コミュニケーション

③連動、支援、誘導

④運用、拡張

21

グローバルにおける環境ブランディングの強化

グローバルに情報を配信するプラットフォーム。

立ち上げ時は欧州と北米を主たるターゲットとして捉え、英語をベースに情報を提供する。

将来的に多言語対応も視野に入れた設計。

次世代の企業コミュニケーションの可能性を探る半ば実験的な側面もある。

各国での通信環境やルーティングなどによる通信速度のストレスを軽減。

プロジェクト要件①

22

ソーシャルネットワークを基盤としたエンドユーザーとのコミュニケーション ソーシャルネットワークを通じた、双方向のコミュ

ニケーションを形成し、強固なブランド基盤の醸成を目指す。

既存サービスやネットワークインフラを最大限に活用して、ユーザとの接点を増やす。

個人情報を保持せずに、ソーシャルネットワークと連携し利用者の参加実績などを記録。

プロジェクト要件②

23

自社の環境活動との連動、マーケティング支援、各国サイトへの誘導 社内各部門の環境コミュニケーションにおける

ウェブのプレゼンスの高まりを受け、総合的な環境コミュニケーションの受け皿を提供する。

各国に対して直接的・間接的な販売支援となるようなブランディング施策を行い、各国のサイトへ誘導する。

プロジェクト要件③

24

スモールスタート、継続運用、随時拡張

一過性のものではなく継続して運用する。

運営事務局・編集部の運用は日本で行う。

小さく生んで大きく育てられるように、スモールスタートから成長させていく計画。

初期投資の負担が少なく拡張性が高い柔軟なシステムが必要。

プロジェクト要件④

施策例プロジェクト要件に対して行ってきた

施策のいくつかを紹介します

26

Facebook(Facebook Connect), Twitter(OAuth), Google(OpenID)

を利用したアカウント連携

アカウント連携をすることにより、利用者の登録情報(個人情報相当分)を保持せずに、利用者毎に実績などの情報を記録・管理することが可能になった。

ユーザ管理機能の構築を最小限に抑え、開発効率を高めることが可能に。

連携先のユーザネットワークへの波及効果を狙った仕組みを実装。

施策例①

27

既存サービスとのマッシュアップによるサイト構築

コンテンツ配信のインフラは、既存のWebサービスを積極的に利用。(動画はYouTube)

アカウント連携したFacebookのファンページやTwitterのつぶやきなどを使った、“出先”での運営側からのコミュニケーションを開始。

施策例②

28

AWSを選択:セキュリティリスクを回避

ウエブサービスとの連携を行うためのシステム構築は、企業の自社ネットワークへ接続するリスクを回避する必要があり、外部サーバでの構築が必要。

施策例③

29

AWSを選択:インフラへの投資とシステム開発の効率化 ハードウエアインフラの構築に必要な時間とコス

トを押さえ、システム構築のみに開発資源を投入することが出来た。

初期投資を抑えながら信頼度の高いインフラを利用したシステム構築を実現。

施策例④

30

AWSを選択:グローバル展開における課題への対応 当初は通信速度にストレスを感じていたため、更

新性が低く利用頻度の高い共通リソースデータや一部の動画などを、AWSのCloudFrontを使って配信することにより、日本を含む各国での通信速度によるストレスを軽減した。

サービスの組み込みの容易さ

検討~設計~実施まで数日間で対応

施策例⑤

31

Amazon Web Services選択の理由

プロジェクト要件

AWSの特長

リスク

3232

プロジェクト要件

グローバルに情報を配信するプラットフォーム。

データセンター拠点は日本ではなく、むしろ海外

開始時北米、ヨーロッパ。それ以外の各国への予定されている。

スモールスタート、継続運用、随時拡張

サーバー環境を最小構成にしながら、将来拡張できるサービスであることが求められる

サービス拡張時にもその要求を阻害しないスピード、構成変更の容易さ、経済性が必要

◆実際にCDN追加をリリース直前に実施

Am

azon Web Services

選択の理由

3333

AWSの特長

選択可能なデータセンター拠点

北米東海岸、北米西海岸、ヨーロッパ

CDN(CloudFront)は日本含め14箇所

Am

azon Web Services

選択の理由

3434

AWSの特長

Am

azon Web Services

選択の理由

Amazon EC2, Amazon Elastic MapReduce

Amazon S3, Amazon SimpleDB

Amazon CloudFrontAshburn, 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

North America and EuropeComing soon: Singapore

3535

AWSの特長

拡張性と可用性

一部に障害が発生しても保存されたイメージですぐに復旧可能

Amazon の信頼性

Pay as you use で必要なときに必要なだけ迅速にサービス追加できる

Am

azon Web Services

選択の理由

出典: 米国RightScale社 (http://rightscale.com/)

3636

AWSの特長

サーバー管理が容易、ツールの選択肢

コマンドラインツール

Management Console 管理画面

クラウドコントロールサービス

APIを利用して独自に組み込むことも可能

Am

azon Web Services

選択の理由

3737

AWSの特長

バックアップ手法・スナップショット

OSイメージまるごと保存も可能

バックアップ処理時間は非常に短い

カスタムイメージ

ミドルウェア導入済み、アプリケーション導入済みのイメージ

同じイメージを使って同時に追加開発ができる

大きな構成変更、サービス追加が可能に

公開直前にCDN追加(検討~設計~実施まで数日間)

Am

azon Web Services

選択の理由

3838

リスク

ウェブサイト実装という面で既存のやり方と比べて生じたリスクは無い

まだまだ事例が少ないため説得が難しい側面も

クライアント担当者以外の関係者

予算化および運用契約では少し注意が必要

基本従量課金のため予算計画の見通しが難しい

費用が完全に確定するのは月末

請求書は発行されずクレジットカードによる請求のみ

Am

azon Web Services

選択の理由

39

Amazon Web Servicesによる変化

プロジェクト計画

プロジェクト体制

ネットワーク設計、サーバー設計

本番環境・開発環境

4040

プロジェクト計画

ハードウェアやデータセンターなどインフラに関わるものは通常かなり早い段階で確定し発注しなければならない

AWS導入前提になると、発注から調達完了まで劇的に短くなるので計画の建て方が変わる

初期構築フェーズでの考え方

追加・変更時のスピード

Am

azon Web Services

による変化

41

プロジェクト計画

AWS導入前

AWS導入後

41

Am

azon Web Services

による変化

テスト開発設計企画

(要件定義)

▲発注 ▲リリース

テスト開発設計企画

(要件定義)

▲リリース

▲調達

▲調達

42

プロジェクト計画

AWS導入前

AWS導入後

42

Am

azon Web Services

による変化

テスト開発設計企画

(要件定義)

▲発注 ▲リリース

テスト開発設計企画(要件定義)

▲リリース

企画→検証→設計→実装

企画→検証→設計→実装

企画→検証→設計→実装

▲調達

▲調達

4343

プロジェクト体制

比較的小さな体制で設計・実装

自分たちでコントロールしやすく

結果として、心理的障壁・物理的な問題が軽減

Am

azon Web Services

による変化

クライアント担当者

プロジェクトリーダー

システムPM

クライアントIT担当

インフラ担当

データセンターベンダー

ハードウェアベンダー

ソフトウェアベンダー

開発担当

クライアント担当者

プロジェクトリーダー

システムPM

クライアントIT担当

開発担当

• データセンター• ハードウェア• ソフトウェア

AWS

4444

ネットワーク設計・サーバー設計

早い段階で確定させる必要があり、かつ稼働し始めると変更しづらいインフラ関連の設計が実装直前まで待てる

データセンター、サーバー構成

ファイアウォール、ロードバランサー、OS/ミドルウェア

バックアップ、メンテナンス作業

一旦稼働させても変更・やり直しがいくらでも可能

Am

azon Web Services

による変化

4545

本番環境・開発環境

本番環境・開発環境の差が無くなる

OS・ミドルウェアインストール、設定済みのイメージを保存し、別のインスタンスで起動

障害調査時の再現環境も直前のインスタンスイメージをコピーして利用

開発環境から本番環境へのリリースは、開発時に準備したリリース用のインスタンスに差し替え、もしくは起動イメージの切り替え

Am

azon Web Services

による変化

46

Amazon Web Servicesで変化しなかったこと

サーバー構成・アプリケーション構成

開発スタイル

4747

サーバー構成・アプリケーション構成

サーバーが完全仮想化されていること、またさまざまはOSやカスタムイメージが存在していることから、何の制約もなく構成の検討ができた。

Am

azon Web Services

で変化しなかったこと

48

Am

azon Web Services

で変化しなかったこと

www1(Web + DB)

Load Balancer

www2(Web + DB)

External Disk

mounted volume

exported volume

mounted volume

Snapshot CDN content

Elastic Load Balancing

EC2

Elastic Block Store

CloudFront edge server

CloudFront edge server

CloudFront edge server

S3

CloudFront

Internet

Internet

負荷対策と冗長化のため2台構成

永続的なデータ保存用ディスク領域

バックアップデータ保存用ディスク領域

CloudFront配信用ディスク領域

コンテンツをNFSで共有

高速にコンテンツ配信

4949

開発スタイル

OSから選択可能なので、開発環境(OS/ミドルウェア/フレームワーク/開発言語)への影響が一切ない

逆に環境準備が劇的に変化

カスタマイズしたオリジナルのOS環境(AMI)を作成

特定のフレームワーク導入済みのイメージ、自社開発フレームワーク導入済みイメージを数分で準備可能

Am

azon Web Services

で変化しなかったこと

これから…

51

AWSへの要望今後取り組みたいこと

DNSホスティング

基本的にCNAMEベースでの連携なので出来ないことがある

例: eco-ideas.net(ホスト名無し)で永続的なロードバランシング

フェールオーバー構成

稼働率と信頼制をさらにあげるためにHeartBeat構成を行い、主要な機能は切り替え可能に(DB・アプリケーションサーバー)

CloudFront ストリーミング

比較的ファイズの大きい動画をストリーミング再生にすることでコンテンツ再生のパフォーマンスを改善

これから・・・

52

まとめ

53

プロジェクトの視点から

インフラなどの要件決定(時間的・物理的)の制限から解放され、目的や成果など様々な条件を考慮した上で意思決定することが可能に。

ハードウエアの納品や設定、ネットワーク構築など、プロジェクト設計上遅延やコスト増大につながるリスクが極小に。

インフラが資産ではなく従量型サービスになる。

まとめ

54

実装技術の視点から

AWS導入による変化はインフラの考え方の変化

であって、ウェブサイト実装手法の変化は全くない。

サーバー構築は論理的な設計でほぼ完了するため、物理的な課題(場所、容積、電源)から解放され、本来やりたいことに集中できる。

完全仮想化されたAWSに乗せることで、他では

得られない拡張性、可用性、運用手法を得ることができる。54

まとめ

5555

ありがとうございました

小島英揮Amazon Data Services Japan株式会社 マーケティングマネージャー

Phone: 03-4288-4221 e-mail: hidekio@amazon.co.jp

青木誠株式会社ビジネス・アーキテクツ 取締役、シニア・アートディレクター

Phone: 03-3431-2511 e-mail: maoki@b-architects.com

後藤和貴テクニカルディレクター

web: www.aws-plus.com e-mail: kaz@aws-plus.com

Recommended