新時代の幕開け、サーバーレスアーキテクチャの衝撃!...
TRANSCRIPT
アジェンダ
☁ cloudpackについて
☁ サーバーレスアーキテクチャの時代 ☁ Lambdaを使った開発とは
• コスト編 • セキュリティ編 • Lambdaファースト編
☁ Lambda関連事例
☁ まとめ
後藤 和貴@kaz_goto
執行役員 / エバンジェリスト
☁ cloudpack事業 執行役員 • エバンジェリスト • マーケティング担当(PR、ウェブ…)
☁ バックグラウンド • Oracle カスタマーサポート→開発 • ビジネス・アーキテクツ • テクニカルディレクター(フリーランス)
r r✤
✤ r✤ r✤AWS r m r m
✤ m
✤ EC2✤ ” r }m EC2
✤EC2 “ } CodeDeploy Elastic BeanstalkmOpsWorks
AWSJ西谷氏講演資料 “Scale Your Business with Managed Servers” より引用
サーバーレスアーキテクチャとは
☁ サーバーの存在について考える必要のないマネージドサービス
☁ ビジネスロジック以外のことを任せられるアプリケーション実行環境
☁ 結果アプリケーションコードだけに集中できる
Lambda : r m r r r
AWS Lambda
a [ vf h
}
100ms r
[ s
” rm m
”
r r “ mLambda
AWSJ西谷氏講演資料 “Scale Your Business with Managed Servers” より引用
AWS Lambda✤ “ ” r r
r r✤ AWS✤AWS r ” r
✤ r }✤VPC r
✤Lambda function✤JavaScriptsNode.jst JavamPython✤ r r
AWSJ西谷氏講演資料 “Scale Your Business with Managed Servers” より引用
オンプレからクラウド(EC2)へ
☁ オンプレミス
• 使っても使ってなくても購入したサーバーの数だけコストがかかる
• Max分だけサーバーを調達
☁ クラウド(EC2)
• 必要な分のみ都度サーバーを調達(スペック/数)
責任共有モデル
☁ データセンターの物理的ファシリティ、ネットワーク・ハイパーバイザなどクラウド基盤の部分はAWSが責任をもつ
☁ 基盤以外の部分はオンプレミスと同様の考え方でユーザー責任
☁ 必要に応じて外部パートナーのソリューションも必須
EC2での責任共有モデル
• SOC 1/SSAE 16/ISAE 3402 • SOC 2 • SOC 3 • FISMA, DIACAP, and FedRAMP • DOD CSM Levels 1-5 • PCI DSS Level 1 • ISO 9001 / ISO 27001 • ITAR • FIPS 140-2 • MTCS Level 3
cloudpackが支援に入った場合のモデル
EC2 → Lambda 責任分解点の変化
アプリケーション
• ファシリティ• 物理セキュリティ• コンピュートインフラ
• ストレージインフラ• ネットワークインフラ• 仮想レイヤー
• ネットワーク設定• パラメータチューニング• 監視/バックアップ/障害対応
• セキュリティ設定• アカウント管理
OSやミドルウェアも含めほとんどが利用者の責任
利用者
データ
ミドルウェア 運用ツール
OS
EC2の場合
責任分岐点
アプリケーション以外はAWSの責任
Lambdaの場合
利用者
アプリケーション
• ファシリティ• 物理セキュリティ• コンピュートインフラ
• ストレージインフラ• ネットワークインフラ• 仮想レイヤー
• セキュリティ設定• アカウント管理データ
• ネットワーク設定• パラメータチューニング• 監視/バックアップ/障害対応
ミドルウェア 運用ツール
OS
責任分岐点
クラウドファースト
☁ クラウドファーストとは、企業が情報システムの設計や移行に際してクラウドサービスの採用を第一に検討する方針のこと
☁ クラウドの「制約」と「実績」が浸透し、クラウドの利点がオンプレの利点を上回った結果
Lambdaファースト
☁ Lambdaファーストとは、企業が情報システムの設計や移行に際してLambdaの採用を第一に検討する方針のこと
• AWS Lambdaを採用を第一に検討するということは必然的にクラウドネイティブなシステムを検討することになる
☁ 気づいたらcloudpackのエンジニアはLambdaファーストな思考になっていた
• 社内で「制約」と「実績」の浸透が暗黙的に始まっている
代表的な制約
☁ 利用できる言語 • Python、Node.js、Java
☁ タイムアウトは最大で5分 • 5分以上の処理はできない
☁ 同時起動数はアカウント(リージョン)あたり100
• 上限アップの申請は可能
☁ VPCサポート機能ではENIが利用される
• ENIの作成の上限が存在(サブネット/EC2の数)
代表的な実績(後述)
☁ EC2を使わないWebシステム • API Gateway + Lambda ☁ 頻度の少ないPush配信システム
• Lambda + SNS ☁ 運用ツール
• Lambda + S3 / CloudWatch
キタ━━━━(゚∀゚)━━━━ッ!!
そういえば6年前も…
☁ AWSに衝撃を受けながらも、クラウド環境下での開発ナレッジを提供・拡散
☁ その結果新規顧客を獲得、クラウド上のでシステム構築・運用まで行うことで成長してきた
日本放送協会様 第66回NHK紅白歌合戦
https://cloudpack.jp/casestudy/117.html
☁ 大晦日4時間半リアルタイム進行 ☁ RabbitMQ + WebSocketで同時
数十万接続 ☁ 生放送中にセカンドスクリーン
アプリにアーティストや楽曲情報が配信される
☁ リアルタイムにアーティスト情報、中間投票、最終投票の様子を集計・表示
EC2を使わないWebシステム
☁ 要件 • ユーザーが画像をアップロード • 画像変換を行いS3&DynamoDB
へメタデータ保管 • アップロードした画像をランダ
ムに取得して表示 ☁ ポイント
• SQSを入れることでDynamoDBへの集中アクセスを回避
コストの単純比較(参考)
☁ Lambdaの場合 • ¥5,000
• 1ドル = 120円
☁ EC2を使った構成の場合 • ¥10,000
• 1ドル = 120円 • EC2/RDSのインスタンスタイプ
は「t2.micro」として計算
頻度の少ないPush配信システム
☁ 要件 • S3にPush送信対象リストを
アップロード
• 短時間でPush送信
• 1日1回実施
☁ ポイント
• S3にファイルが配置されるタイミングでLambdaを起動
• 並列にファンクション実行
コストの単純比較(参考)
☁ AWS Lambdaの場合 • ¥1,000
• 1ドル = 120円
☁ EC2を使った構成の場合 • ¥5,000
• 1ドル = 120円 • EC2のインスタンスタイプ
は「t2.micro」として計算
☁ 攻撃状況をダッシュボードで可視化 • 外部からの攻撃ログをKinesis経由で保管
• 生ログはS3保管、ミラーしてLambdaでフィルタ後にさらにKinesisへ
• フィルタ・整形済みログをS3へ→INCAPSULA/AKAMAI両ログの共通化
生ログ保管ログ整形
フィルタ
☁ 攻撃状況をダッシュボードで可視化 • 分析済み生データはRedshiftへ • 管理画面で必要な即時データ(キャッ
シュ)はJSONでS3保管 • 管理画面(ダッシュボード)表示はAPI
Gateway経由でアクセス
生データ分析
JSON保管
管理画面
運用ツール
☁ S3/CloudWatch Logsに出力されたログの監視 • キーワードを検出したら通知
☁ AWS IPレンジ更新→差分記録&WAF登録 • SNS→Lambda→S3保管+Backlog起票 • WAFのAWS IPレンジ更新
☁ ENIの数のモニタリング • CloudWatchのカスタムメトリクスとして登録
まとめ
☁ サーバーレスアーキテクチャの採用は、 コスト最適化・運用負担軽減などメリットが大きい
☁ LambdaはAWS上の既存仕組みに馴染んで 自然に効果を発揮する
☁ クラウドファーストは時代遅れ(当たり前)時代はLambdaファーストへ
cloudpack ホワイトペーパー 4兄弟
クラウドセキュリティ
サーバーレス開発 ホワイトペーパー(AWS Lambda)
サポートデスク(運用) 専用線接続 (AWS Direct Connect)
部数限定 cloudpack ブースで頒布中!
AWS Summit会場限定 先行頒布