Amazonを支えるクラウドとは

2019/9/19 ESD21 会員例会

自己紹介
• 所属

有限会社スクラッチソフト• 名前

川路義隆（かわじよしたか）• 仕事

システム受託開発
AWS構築・運用案件のサポート

今日のターゲット• 「クラウド」というフレーズは理解しているが良さがわからない• 既存のシステムをクラウドへ移行するメリットがわからない• SIベンダーに相談したら「クラウドは危ない」、「クラウドは高い」と言われたというような方向けですAmazonとは

低コスト体
質・構造

低価格
品揃え

出店社

成 長

顧客数

顧客体験

Amazon Go : 新しい形の店舗のスタイル• レジのないコンビニ• お客さまは商品をピックアップし、そのままお店の外に出ていただくことで買い物が完了• Amazon.comのアカウントにチャージ• 画像認識を中心としたさまざまなテクノロジーで手に取った商品を把握Amazon Robotics

・Amazonの倉庫の効率化をRobotで行うことを研究するために設立
・配送センター内の作業を、ロボット工学を用いて自動化することを研究「自律移動」「言語認識」「物体認識」などを機械学習テクノロジを用いて実施
・神奈川県川崎市の新物流拠点「アマゾン川崎FC」（フルフィルメントセンター）で導入

今日はこのように成長を続ける
Amazonが手がけているAWSを紹介します初期のAmazon.comの課題• システムがスケールしない• 自社またはデータセンター会社の増設が追いつかない• 高いハードウェア・ソフトウェア購入費用• サービスの追加や改善がインフラ要件で遅延Amazon Web Services(AWS)
amazon.comの課題を解決するために生まれたテクノロジーがAWS• 予め大規模に投資し準備する• データセンター、サーバー、ストレージ機器•必要な時に、必要なときだけ、低価格で初期投資不要、実際使用分のみ支払い、容易なスケールアップ&ダウン、定額の変動費、スピード、市場導入と俊敏性の改善

AWSのビジネスの現状• 47% 昨年度比の成長• 数百万を超える利用ユーザー数

利益推移(Q4 2018)
Amazon全体の純利益

AWSだけの売上・利益推移

利益推移(Q4 2018)
Amazon全体の純利益

AWSだけの売上・利益推移
21億7700万ドル

３０億２７００万ドル21億7７００万ドル

AWSの機能改善、新規サービス提供スピード
2000

1500

1000

500

0

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

165以上のサービス郡

なぜAWSを利用するか• ビジネス価値を出す開発に注力したい
そうでないものはAWSに任せる• 可用性
オンプレミスを利用すると人的リソースへの費用が高額になる上に、質もAmazonのサポート体制より下になる• コスト最適化
初期投資不要、ランニングコスト部分についてAWSは継続的な値下げをする文化• セキュリティ維持コストを下げたい※後ほどお話しますビジネス価値を出す開発に注力したい165以上のサービス郡

165以上のサービス郡
アプリケーション

AWSの各種サービスを利用した上で、ビジネス価値を生み出すアプリケーションを載せていく。

コスト
初期投資不要、事前のサイジング（見積）にかける人的コスト大幅削減

従来のインフラ構成の見積り方法
要件定義を行い要件から非機能要求を洗い出しCPU性能、メモリサイズを検討
データベースはどれぐらいのデータが蓄積されるかピーク時にどの程度アクセスが有るか？

従来のインフラ構成の見積り方法
要件定義を行いだいたい後で変更・追加要件から非機能要求を洗い出し
CPU性能、メモリサイズを検討
データベースはどれぐらいのデータが蓄積されるかピーク時にどの程度アクセスが有るか？

従来のインフラ構成の見積り方法
要件定義を行いだいたい後で変更・追加要件から非機能要求を洗い出し

根拠に乏しい願望を列挙

CPU性能、メモリサイズを検討
データベースはどれぐらいのデータが蓄積されるかピーク時にどの程度アクセスが有るか？

従来のインフラ構成の見積り方法
要件定義を行い

だいたい後で変更・追加要件から非機能要求を洗い出し

根拠に乏しい願望を列挙

CPU性能、メモリサイズを検討 まだ見ぬ完成後のシステムのパフォーマンス
データベースはどれぐらいのデータが蓄積されるかピーク時にどの程度アクセスが有るか？

従来のインフラ構成の見積り方法
要件定義を行い

だいたい後で変更・追加要件から非機能要求を洗い出し

根拠に乏しい願望を列挙

CPU性能、メモリサイズを検討 まだ見ぬ完成後のシステムのパフォーマンス
データベースはどれぐらいのデータが蓄積されるか要件絶対変わらないならば・・・

ピーク時にどの程度アクセスが有るか？

従来のインフラ構成の見積り方法
要件定義を行いだいたい後で変更・追加要件から非機能要求を洗い出し

根拠に乏しい願望を列挙CPU性能、メモリサイズを検討 まだ見ぬ完成後のシステムのパフォーマンス
データベースはどれぐらいのデータが蓄積されるか要件絶対変わらないならば・・・

ピーク時にどの程度アクセスが有るか？
分かるわけがない。まだリリースしていないシステムなのだから

従来のインフラ構成の見積り方法とはいえ我々はこの課題に長年立ち向かってきました従来のインフラ構成の見積り方法

みなさん分かりますよね？

従来のインフラ構成の見積り方法

バッファを積む！！

従来のインフラ構成の見積り方法
エンジニアの検討結果

営業の提出見積り

エンジニアの提出見積り

失敗は許されない

失敗は許されない

見積り完了まで数週間から数ヶ月とかよくあります
誰もが真剣に時間を使い数字と向き合っているが、精度を高める困難さこのような過剰な見積の結果起こること

AWSを利用した場合
課題:CPU性能、メモリサイズが不足しそう
Amazon EC2
数分で起動、１秒毎の従量課金で利用可能な仮想サーバー
CPU,メモリ,I/O・GPUなど特徴を持ったインスタンスファミリーを提供
稼働後も一時停止し、必要な性能を持ったインスタンスとしてスケールアップ/ダウンが可能

AWSを利用した場合
課題:データベースのストレージサイズが不安
Amazon RDSMySQL, Oracle, SQLServer, PostgreSQL, MariaDB, Auroraから選択可能。
バックアップやフェイルオーバーに対応したDBを数クリックで利用可能。
メンテナンスコストを大幅に削減(パッチ当てやバックアップはAWSが行ってくれる)
中でもAuroraを選択している場合は最大64Tまでディスクサイズ自動拡張

AWSを利用した場合
課題:ピーク時に機会損失なくシステムを可動させたい
Elastic Load Balancing

複数のAmazon EC2インスタンスに負荷分散
複数のアベイラビリティゾーンに跨って、高レベルの耐障害性を実現
ELB自体が自動的にキャパシティを増減

Auto Scaling
事前に指定した閾値・条件によりAmazon EC2を増減させることが可能
特定の時間だけサーバーを100台、深夜は５台などのコントロールも可能

AWSを利用した場合
課題:バッチ処理の負荷・コストを下げたい
AWS Batch
指定したスケジュールに起動させ、処理が完了時点でサーバーを破棄することが可能
処理する際に利用するAmazon EC2のインスタンス種別は自由に指定できる為、ハイスペックなマシンをバッチ処理中だけ利用することが出来る可用性
可用性とは「システムが継続して稼働できる能力」のこと

まず知っておくべき事リージョンとアベイラビリティゾーン
リージョンは複数のアベイラビリティゾーン(AZ)で構成
AZは、複数のデータセンターによって構成され、高い対障害性を提供

20のリージョン、１のローカルリージョン、６１のアベイラビリティゾーン、100+のエッジロケーション
日本にいながら全世界へサービス展開可能オンプレミスのよくある構成
FW
FW

ルーター
ルーター

各ハードウェアを冗長化しハードウェア障害などに備える構成

LB
LB
WEB
WEB
AP
AP
DB
DB
ストレージ
ストレージ
データセンター

金融機関、一部大規模サービスを除き一般的にデータセンター全体への障害には対応できない。(予算的に)

AWSに置き換えしてみる
リージョン
アベイラビリティゾーン

アベイラビリティゾーン

LB

データセンターを跨いだ形での冗長化が設定のみで行える障害発生時にはAWS側のサービスとして切

WEB

WEB

AP

AP

DB

DB

り替えが行われる
ELB(ロードバランサー)

EC2(仮想サーバー)

RDS(データベース)

類似な環境を用意できる
リージョン

FW
FWルータールーター

アベイラビリティゾーン

LB

LB
LB
WEB
WEB
AP
AP
DB
DB
ストレージ
ストレージ
データセンターアベイラビリティゾーン

WEB

WEB

AP

AP

DB

DB

類似な環境を用意できる
リージョン

FW
FW

ルーター
ルーター

アベイラビリティゾーン

類似な環境を実現するだけではなく、
LB

アベイラビリティゾーン

LB

LB

可用性が上がっている。

ポイントは WEB
WEB
リージョン
AP
AP
アベイラビリティゾーン
DB
DB
ストレージ
ストレージ
データセンター

WEB

WEB

AP

AP

DB

DB

可用性をおろそかにすると先月発生した大規模障害で数多くのサービスが一時利用不可に「ものは壊れる」を前提とした設計が求められる都市伝説
クラウドというフレーズが浸透してきた現在でも数多くの事実とは異なり誤解釈された常識というものがあります。
日々いろいろな方から質問をされる代表的な「誤解された内容」を「都市伝説」として一部紹介します。

その１：オンプレミスの方がクラウドより安全だ

AWSの責任共有モデル
利用者が責任を持つ範囲

AWSが責任を持つ範囲

AWSのセキュリティ

AWSのセキュリティAWSを利用することでこれらのセキュリティが付いてくる
現実問題同レベルの第三者認証/認定を取得し維持し続けることは困難かつ高コストセキュリティ関連AWSサービスが豊富

その１：オンプレミスの方がクラウドより安全だ
事実
AWS環境では様々な認証や認定を取得しているため、オンプレミスと同等、もしくはそれ以上のセキュリティを効率的に実装が可能です。

その２：クラウドは仮想サーバーを貸しているだけ

165以上のサービス郡

165以上のサービス郡

AWSのサービスを利用することで、よりビジネス価値の高い部分だけに注力することが出来る。
AWSのサービスに存在しないものだけを開発していけばよい。

その２：クラウドは仮想サーバーを貸しているだけ
事実
AWSでは仮想サーバーも提供しているが、豊富なサービスラインナップを組み合わせてシステムを構築できる点が従来のシステム開発と異なる点である。

既存システム移行

オンプレミス基幹システムを移行する
おすすめ手順の紹介

TCOの検討を行う• TCO(Total Cost of Ownership)とは「総保有コスト」のことで、ある設備などの資産に関する購入から破棄までに必要な時間と支出の総計。

• 予算を作成する時に、ランニングコストとして必要になる経費を考慮に入れず初期投資額だけに注目しがちなので注意が必要。

AWS

オンプレミス

初期投資０円

初期投資

ランニングコスト
見落としがちランニングコスト

5年

AWSはランニングコスト積算 > オンプレミスの初期投資
結果AWSが高い！という見積りが出たら要注意

5年

AWSの料金に含まれるもの• データセンター費用• 運用人件費• サーバ機器(代替機含む)• バックアップソフトウェア• ネットワーク機器• データ暗号化機能• 機器保守費用• 特権管理機能• 電源費用• リソース監視モジュール• OS費用適切なサイジング

例. 基幹システムをクラウド化したい
シナリオとある企業様が１０〜２０存在する既存システムをクラウド移行したいと要望

手順• 手始めに比較的小さなシステムを移行する
まずはお客様にAWSを理解・体感してもらう• 移行する中でペースを上げ、中核となるシステムの移行も検討
コスト感覚を養ってからが良い

小さく移行ができないケースの対処法
移行計画が難しいケース

システムB

システムA

システムC

複数のシステムが密に連携をとっているため、個別の切り離しが難しい

小さく移行ができないケースの対処法
オンプレミス

AWS

高速な専用回線

システムB

システムA

高速な専用回線を利用し、ネットワーク遅延を極力抑えシステ
ムの部分切り出しを行うことが可能。
システムC

この移行期に発生する状況を「ハイブリットクラウド」と呼ぶ

AWS Direct Connectその他 Amazon EC2 Bare Metalその他 VMware Cloud on AWS

「クラウド化しない！」
or「一気に一大プロジェクトとして移行しよう！」の両者択一ではなく計画的移行を行いましょう。

ご清聴ありがとうございました