頑張らないクラウド最適化〜クラウドネイティブだけでないAWS活用〜

#cmdevio2016 #A

Developers.IO 2016

A-1

ソリューションアーキテクト⼤栗宗クラスメソッド株式会社

Ⓒ Classmethod, Inc.

2016年02⽉20⽇

頑張らないクラウド最適化〜クラウドネイティブだけでないAWS活⽤〜

1

#cmdevio2016 #A

2Ⓒ Classmethod, Inc.

#cmdevio2016 #A


この時間帯の⽬⽟「DynamoDBによる

グラフデータベースの構築」は11Fですよ！

間違えてませんか？？？

#cmdevio2016 #Aお前誰よ？⼤栗宗（@maroon1st）AWS導⼊のコンサルティングや構築を⾏っています。執筆に携わった書籍が来週でます！I ♥ ウィスキー, シガー, パイプ好きなAWSサービス：• RDS• CloudWatch


#cmdevio2016 #AAgenda

• クラウド最適化• 『頑張らない』とは？• Web/APサーバの最適化• ネットワーク構成の最適化• オンプレ→AWS化→最適化• まとめ


#cmdevio2016 #A

クラウド最適化とは？

#cmdevio2016 #A


Developer.IO 2016に参加されている皆さんはクラウド(特にAWS)を

使ってますよね？

#cmdevio2016 #A


ではAWSを『使いこなして』

いますか？

#cmdevio2016 #A


『使いこなすこと』つまり

『利⽤の最適化』は極めて難しい

#cmdevio2016 #Aクラウド利⽤の最適化とは？AWSを使いこなしているかをチェックするには「AWS Well-Architected Framework」によると4本の軸があります。（内容は「AWS Well-Architected Framework」を参考にしていません）

• セキュリティ• 信頼性• パフォーマンス効率• コストの最適化http://d0.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf


#cmdevio2016 #Aセキュリティ

• 責任分担モデル（shared）• AWS提供部分はAWSが責任をもち、ユーザ設定部分はユーザ

が責任を持つ

• 『⾃由度』＝『責任』• マネージドサービスは⾃由度が下がる分、責任が減る

• 世界最⼤級のECサイトと同程度のセキュリティ対策• 多数の第三者認証• AWSに「責任を押し付けて」セキュリティを上げる


#cmdevio2016 #A信頼性

• オンプレミスの考え⽅• 代替機の準備が⼤変• サーバ１台１台の信頼性を⾼める（メインフレームやスト

レージアプライアンス）

• AWSの考え⽅• 無限に代替機がある• コモディティサーバで⾼速に切り替える• マネージドサービスは冗⻑化済みor⾼可⽤性な構成を組める


#cmdevio2016 #Aパフォーマンス効率• ⼀般的にはクラウド環境ではスケールアウト

• 今後はスケールアップも現実的（X1は2Uのフルスペックレベル）

• ステートレスかステートフルで拡張戦略を使い分ける• ステートレスサーバ：

状態を持たないためスケールアウトが⼀般的。ソフトウェアのライセンスによってはスケールアップも検討。

• ステートフルサーバ：データの再配置に⼤きな負荷がかかるためスケールアップを優先して考える（⼤規模データは除く）。10TBオーダーのデータ量の場合はスケールアウトを考慮。


#cmdevio2016 #Aコストの最適化

『コストの最適化』≠『コストが低い』• 固定費から変動費へ

• 使⽤料利⽤状況に合わせたコストを⽀払えば良い

• 運⽤にかかる⼈件費の低減• サーバのランプチェックやディスク交換の⼈件費は不要

• すぐに終了可能• リース費⽤や最低利⽤期間がない

• 柔軟な⽀払いオプション• Reserved InstanceやSpot Instanceを選択可能


#cmdevio2016 #A

『頑張らない』とは？

#cmdevio2016 #Aクラウド適⽤の分類独⾃にクラウドの適⽤レベルを分類してみる（スピーカー独⾃の分類です）


クラウドレガシー

ニューレガシー

クラウドネイティブ

低 AWSの活⽤度⾼

クラウド

ア｜キテクチャ

オンプレミス

#cmdevio2016 #Aクラウドレガシー

レガシーシステムをクラウド上に展開している状態(スピーカーの独⾃⽤語/定義です)

• AWSの使⽤⽅法を理解できていない。• 物理サーバをEC2に置き換えただけ。• システムのアーキテクチャはオンプレミスと変わらない。


初期費⽤

○？

修正は最⼩限

AWS利⽤料

☓

EC2ばかりで購⼊オプション無し

運⽤費⽤

☓

マネージドなサービス無し

#cmdevio2016 #Aニューレガシー

オンプレミスのアーキテクチャの延⻑で発展した状態(スピーカーの独⾃⽤語/定義です)

• オンプレミスのアーキテクチャを踏襲• 積極的にマネージドサービスを活⽤• 必要はアプリケーション改修は⾏う


初期費⽤

△

ある程度の修正コスト

AWS利⽤料

△

EC2を使う場合は購⼊オプションを使⽤

運⽤費⽤

△

マネージドな部分は負荷低減

#cmdevio2016 #Aクラウドネイティブ

クラウドの特性を前提としたアーキテクチャ(スピーカーの独⾃定義です)

• マネージドサービスを積極活⽤• ⾯倒なことをAWSへ押し付ける• サービス利⽤により余計な開発は不要


初期費⽤

○ / △ / ☓

内容により⼤きく変動

AWS利⽤料

○

EC2は最⼩限

運⽤費⽤

○

ほとんどマネージドサービス

#cmdevio2016 #A頑張らないクラウド最適化

• 頑張らない？• クラウドレガシー• ニューレガシー• クラウドネイティブ

• インフラはクラウド推進だが、アプリは既存設計→アプリが「頑張らない」分をインフラが「頑張る」


#cmdevio2016 #A


『頑張らない』クラウド最適化＝

インフラ担当が『頑張る』

#cmdevio2016 #A

Web/APサーバ最適化の例

#cmdevio2016 #AクラウドレガシーなWeb/APサーバ

典型的なAWSを使いこなしていないWebシステム


virtual private cloud

LBDB on EC2

C1アプリA

C1アプリB

URLのパスで割り振る

#cmdevio2016 #A

#cmdevio2016 #Aクラウドレガシーの懸案事項

• 商⽤ロードバランサの導⼊で⾼コスト• URLのパスによって後続のEC2（アプリ）が異なる

• DBはEC2上に構築• バックアップ、障害回復は⼿動で対応するの？

• Web/APサーバが旧世代インスタンス• C1では仮想化タイプがPV。パフォーマンスが悪い。


#cmdevio2016 #Aニューレガシーの例

レガシーシステムをクラウド上に展開している状態

25Ⓒ Classmethod, Inc.virtual private cloud

アプリA

アプリB

CloudFront

ELB

ELB

S3 bucket

RDSC3

C3

Auto Scaling group

Auto Scaling group

CloudWatchLogs

アプリデプロイ済AMI

ElastiCache

#cmdevio2016 #Aニューレガシーでの改善案

• CloudFrontをReverse Proxyとして使う• Behaviorの設定でパス毎にアクセス先を変更可能• 同⼀ドメインでも特定パスをS3に向けることができる。

• DBはRDSでマネージドに• 無停⽌⾃動バックアップ、PITRに対応。• 最近はTimezoneの変更も可能などアップデートもある。

• Web/APサーバは設定のコード化、ステートレス化• マシンイメージの切替えが可能で仮想化タイプを変更できる。• ステートレスのためAutoScaleでの台数の増減が可能。


#cmdevio2016 #A

ネットワーク構成最適化の例

#cmdevio2016 #Aクラウドレガシーなネットワーク構成




NAT

ELB

Public Private

S3 Bucket

IPアドレス

ElastiCache

RDS

AP2

AP1

CloudWatch

#cmdevio2016 #Aクラウドレガシーの懸案事項

• 外部への通信が全てNATインスタンスを経由する• インスタンスタイプにより帯域が制限される。• 冗⻑化するには⾃分で仕組みを構築する必要がある。

• S3との通信でNATインスタンスが逼迫する• S3への通信は殆どが⼤容量のため、他の通信の帯域を奪う。

• インスタンス間の通信はIPで⾏う• インスタンスの⼊れ替え時にアクセス元全ての設定を変更す

る必要がある。






ELB

Public Private

S3 Bucket

hostnameAmazon

RDS

AP2

AP1

CloudWatch

endpoints

NAT gateway

flow logs

ElastiCachePrivate

PrivateDNS

#cmdevio2016 #Aニューレガシーでの改善案

• 外部への通信はNAT Gateway経由する• NAT Gatewayは帯域が広く、冗⻑化されている。• 通信がない時の待機コストが低い。

• S3との通信はVPC Endpointを使⽤する• 他の通信の帯域を消費しない。

• インスタンス間の通信はホスト名で⾏う• Private DNSの使⽤で、インスタンス⼊れ替え時はRoute 53

のみ変更すれば良い。名前解決のTTLに注意。


#cmdevio2016 #A

オンプレ→AWS化→最適化

#cmdevio2016 #AオンプレミスのWebシステムの例


#cmdevio2016 #Aオンプレミスの構成内容

• ロードバランサーはハードウェアアプライアンスを使⽤している

• 共⽤するストレージとしてNFSをマウントしている

• バックアップはテープドライブにしている

• バッチサーバは特定の時間帯のみ処理を⾏う


#cmdevio2016 #Aクラウドレガシーの例


#cmdevio2016 #Aクラウドレガシーの構成内容

• ⼤きな変更点• バックアップ先をテープからS3へ変更• メールサーバを廃⽌して、SESでメールを送信• ロードバランサをアプライアンスからELBへ変更

• 問題点• AWSのSLAの定義を満たしていない• 障害発⽣時に復旧処理を⾏う必要がある• バッチサーバの利⽤時間が少ない


#cmdevio2016 #Aニューレガシーの構成内容

• Web/APサーバをMulti-AZで配置する• DBサーバはRDS化してMulti-AZ構成とする• Auroraの使⽤で99.99%の可⽤性のDBサーバ• Web/APサーバのAuto Scaling適⽤で、障害発⽣時に

⾃動で復旧する• バッチサーバは必要な時間帯にSpot Blockで起動して

コストを抑える


#cmdevio2016 #A

まとめ

#cmdevio2016 #Aまとめ• 導⼊レベルの分類

• 導⼊するチームメンバーが持っているスキルを考慮しAWSの導⼊レベルを決定→『頑張らない』クラウド最適化


初期費⽤ AWS利⽤費運⽤費⽤備考

クラウドレガシー ○？ ☓ ☓ AWSに最適化できていない

ニューレガシー △ △ △ インフラだけでできる最適化を⾏う

クラウドネイティブ ○ / △ / ☓ ○ ○ インフラとアプリの両⾯で

最適化を⾏う

#cmdevio2016 #Aまとめ

• AWSの主要サービスについて代表的な利⽤ケースとそのメリットを把握する。AWS CDP等が参考になる。

• 各サービスを低いハードル（アプリ改修が少ない）で導⼊する⽅法を考える

• 導⼊が容易なサービスはメリットがあり、コストに問題が無ければ積極的に活⽤していく。


#cmdevio2016 #A

宣伝

#cmdevio2016 #A

宣伝その２

#cmdevio2016 #AAWSエキスパート養成読本が出ます！


#cmdevio2016 #A


#cmdevio2016 #A


2⽉26⽇発売予定です。是⾮お買い上げ下さい！2⽉26⽇発売予定です。是⾮お買い上げ下さい！

#cmdevio2016 #A

宣伝その３

#cmdevio2016 #A


みなさんAWSエキスパート養成読本

欲しいですよね？

#cmdevio2016 #A


懇親会まで参加すると抽選でプレゼント！

#cmdevio2016 #A


ANY QUESTIONS ?

頑張らないクラウド最適化〜クラウドネイティブだけでないAWS活用〜

Technology

Transcript of 頑張らないクラウド最適化〜クラウドネイティブだけでないAWS活用〜

頑張らないクラウド最適化 〜クラウドネイティブだけでないAWS活用〜

Technology

Transcript of 頑張らないクラウド最適化 〜クラウドネイティブだけでないAWS活用〜

頑張らないクラウド最適化〜クラウドネイティブだけでないAWS活用〜

Transcript of 頑張らないクラウド最適化〜クラウドネイティブだけでないAWS活用〜