あらゆるログデータを分析し、機械学習さえも実現するAWSインフラの脅威とは?

あらゆるログデータを分析し、機械学習さえも実現するAWSインフラの脅威とは?

AWSを利用して、シンプルなコーポレートサイトはもちろんのこと、分析用のシステム基盤作りや機械学習用のインフラ構築まで、どんなインフラ構成で作るべきかが書かれた本でした。

EC2やS3を使ってインフラを構築することくらいは、一般的になりつつはあります。

でも、EMRを利用したぐちゃぐちゃな状態のログの構造化、そして構造化したデータのRedshiftを通じた処理、その結果をTableauで分析するなど、その一連の流れまで対応できているサービスは、意外と少ないのかとは思います。

しかし、これらの仕組みをたった一つのAmazonという企業が保持しているのはものすごいすね。

Amazonへの過度な依存は怖い部分はあるとはいえ、この便利さを踏まえたら、もうインフラのクラウド化の流れから逃げようはないす。

そういう意味では、いかにこういったサービスをフル活用して、最短でサービスを常に新しくしていくかが問われそうです。

ありがとうございます!

本のまとめ

▼読んだ本は?

■Amazon Web Services 定番業務システム14パターン 設計ガイド
■ 川上 明久 (著)

▼コーポレートサイト構築時のインフラは?

【1】EC2(仮想サーバー)+EBS(Elastic Block Store/仮想ストレージのこと)
└WEBサーバーとして利用

【2】ELB(Elastic Load Balancer)
└WEBサーバーを冗長化するための、ロードバランサーとして利用

【3】RDS(Relational Database Service/RDBMSサービスがセットアップ済みで提供されるサービス)
└データベースサーバーとして利用

【4】CloudFront(AWSにより世界中に配置されたサーバーが、WEBアクセスをキャシュしておくサービス)
└CDNとして、静的コンテンツの配信に利用

▼可用性重視のWEBシステムでのインフラは?

【1】EC2
└WEBサーバーとして利用

【2】ELB
└WEBサーバーを冗長化するための、ロードバランサーとして利用

【3】Cloud Watch(監視サービス)
└障害を早期に検知して、再起動するための監視として利用

【4】ローカルリージョン
└メインリージョンと同一の構成で、バックアップサーバーを配置しておくリージョン

【5】RDS
└「クロスリージョンレプリケーション」機能を利用して、バックアップサイトにデータを同期しておく

【6】Route53
└「DNSフェイルオーバー」機能を利用して、メインリージョンで障害を検知したら、ローカルリージョンにアクセスを切り替える

▼ELB設定時のポイントは?

【1】ELBとWEBサーバーでは異なるセキュリティグループを設定
└ELB:どこからでもHTTP・HTTPSのアクセスを許可
└WEBサーバー:ELBからのHTTPリクエストしか受け付けないようにする

【2】セッション維持機能を保持
└ELBではCookieの情報を元に同一のサーバーに振り分ける「スティッキーセッション」機能を利用

【3】HTTPSの処理
└ELBのリスナー機能にて、ロードバランサーのプロトコルをHTTPS、WEBサーバーをHTTPとすることでサイトをHTTPS化できる
└個々のWEBサーバーに、SSL証明書を管理する必要がなくなる

▼CloudFrontへのアクセスの流れは?

【1】開発者がサイトのhtmlソースコード内に、CloudFrontで割り当てたURLを予め記載
【2】ユーザーがアクセスすると、CloudFrontに対してコンテンツのリクエストを渡す
【3】はじめてのアクセスでCloudFrontにコンテンツキャッシュがない場合、オリジナルコンテンツにアクセスしにいく
【4】一度アクセスされると、コンテンツはCloudFront側にキャッシュされる
【5】次のアクセスから、ユーザーはCloudFrontからコンテンツを提供される

▼AWSでのデータバックアップの方法は?

【1】S3(Simple Storage Service)を使う
└オンラインのファイルサーバーのように管理できる
└バックアップ対象がファイルである場合に有効
└異なるアベイラビリティゾーンにまたがる3重化構成になっており、耐久性は99.999999999%
└ライフサイクル設定で、バックアップデータの保存期間を定義できる

【2】EC2+EBSの利用
└コストは高いが、DBのオンラインバックアップなどができたり、柔軟性が高い

【3】Storag Gatewayの利用
└オンプレミス環境にあるサーバーにストレージ管理の専用ソフトを導入して、AWSと接続してAWS側に自動的にバックアップできる

【4】Glacierの利用
└ログ、DBファイルなど長期保管が必要なデータに最適
└保存データ量あたりのコストが格安で、S3と比較しても5分の1程度
└S3のライフサイクルポリシーに設定することで、一定期間経過後に自動削除とかもできる
└ただ、保管したファイルにアクセスする場合、リクエストしてから3~5時間かかる
└また、無料で取り出せるデータ量に制限がある

▼ファイルサーバーとしてのインフラは?

【1】S3(オブジェクトストレージサービス)を使う
■メリット
└耐久性が99.999999999%と高く、冗長化の考慮が不要
└安価に利用できる
└容量の制限が無いので、拡張性の考慮が不要

■デメリット
└ファイルアクセスにREST APIを利用してHTTP(S)を利用するため、NFSよりレスポンスが遅い
└複数での同時ユーザー利用の制御など、排他制御ができない
└ファイル更新の直後に参照すると、更新前のデータが返される時がある
└そのため複数プロセスから同時に読み書きするアプリケーションでは、意図しない更新結果になることがある

【2】EFS(ファイルストレージサービス)を使う
■メリット
└Linuxからディレクトリ構造のファイルシステムをNFSマウントして利用できる
└アクセス権限の管理、同時接続、読み取り整合性を兼ねる
└読み込み時点のデータが返されることが保証され、ロックもできる
└レイテンシー(応答時間)はS3より小さく(速く)、EBSより大きい(遅い)

▼データ分析システムを構築するときのインフラは?

【1】Redshift
└大量データの検索・分析に向いたDBサービス
└顧客属性データや売上履歴データ、商品データなどを格納することが多い
└MySQLなど通常のRDBMSでは、行全体を読み出す仕組みのため、処理が重くなる
└でも、Redshiftでは顧客グループごとに売上高を集計するような「列方向」のデータ参照に最適

【2】Flydata Sync
└MySQLとRedshiftのデータ連携を、簡単に実行できるツール
└MySQLのバイナリーログから更新情報を取得して、Redshiftに転送できる

【3】Tableau Desktop
└プログラミングなしに、画面上の操作で分析レポートを作成できるツール
└Redshiftにネイティブ対応していて、接続のための開発やコネクターなしでデータ連携できる
└Windowsのデスクトップ上で動作する
└EC2インスタンスにインストールして、リモートデスクトップで接続して利用されることが多い

【4】Tableau Server
└レポート閲覧者が、WEBページとしてダッシュボード上から分析結果レポートを確認できるツール
└データソースであるRedshiftに定期的にアクセスして、分析結果を自動更新することもできる

【5】EMR(Elastic MapReduce)
└Redshiftに取り込むため、ログファイルなど構造化されていないデータを最小限のスキーマ定義でデータ整形できる
└分散処理技術「Hadoop」をベースにしたサービス
└処理の受け付け、監視をする「マスターノード」、処理だけを担当する「タスクノード」などから構成される
└処理能力を向上させたい場合「タスクノード」を増やせばOK

【6】Fluentd(オープンソースのログ収集ソフト)
└各サーバーから定期的にログを収集して、S3にコピーして集約できるツール
└対象のサーバーにインストールして、設定ファイルでプラグイン、フォーマット、出力先S3情報などを指定すればログ収集できる

▼機械学習(ディープラーニング)を行うためのインフラは?

■SageMaker
└ディープラーニングを含む機械学習をサポート
└Tensorflow,PyTouch,Chainer,MXNetなどの機械学習用のフレームワークに対応している

▼コンテナを実行するインフラは?

■ECS(EC2 Container Service)
└EC2インスタンスでコンテナを実行するマネージドサービス
└コンテナとは、Linuxカーネルの機能を利用して、OS内で仮想化されたアプリケーション実行環境を作れるサービス
└コンテナには、アプリケーションそのものや、対象のフレームワークが含まれている
└コンテナの作成と実行には「Docker」が利用される
└1つのEC2インスタンスで、複数のアプリケーションを動かせるので、コスト減少につながる

▼モバイル開発を行うインフラは?

【1】Mobile SDK(ソフトウェア開発キット)
└複数のモバイルアプリ向けライブラリで構成されたソフトウェア開発キット

【2】Device Farm
└AWSのセンターに設置されたさまざまな物理デバイスを遠隔地から操作して、オンラインでテストして結果取得ができる

▼サーバーレスなインフラを構築するには?

【1】Lambda
└何かしらのイベントをトリガーとして、プログラムを実行するサービス
└GETメソッドによりリクエストを送ることで、Lambdaファンクションが呼び出され、プログラムが実行される
└動的コンテンツの処理に利用

【2】API Gateway
└REST APIを定義してリクエストを受け付け、処理するためのサービス
└認証、キャッシュ、セッションステータス管理、API実行状態の監視とロギングなどもできる
└動的コンテンツの処理に利用

【3】CloudFlont
└CDN上でコンテンツをキャッシュして配信する
└静的コンテンツの配信に利用

【4】S3
└ストレージの中に対象ファイルを格納する
└静的コンテンツの格納に利用

関連する記事