Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ゴーファーくんと学ぶAWSサーバーレスの世界/AWS-serverless-learn-with-gopher

 ゴーファーくんと学ぶAWSサーバーレスの世界/AWS-serverless-learn-with-gopher

会社の有志でやっているミニ勉強会で使った資料です。

iwasiman

June 06, 2022
Tweet

More Decks by iwasiman

Other Decks in Technology

Transcript

  1. 先端技術勉強会 技術講習会
    2022年6月
    @iwasiman
    Advanced
    -STUDY GROUP-
    第3回 ゴーファーくんと学ぶ
    AWSサーバーレスの世界
    Technology
    TECH-SESSION

    View full-size slide

  2. 2
    この技術講習会(先端技術勉強会)について
    ⚫ 頻度は月1回?程度、基本1H。時間は夕方がよさそうです。
    ⚫ とりあえず始めてみて様子を見ながら続けます。
    ⚫ 今回もスライドで資料を作りましたが、Web上のリソースなどの参照が
    メインになる回もあるかもしれません。
    ⚫ 説明中も適宜間を挟むので、リアクションはその都度音声でもチャット
    でもOKです!
    ⚫ テーマはフリー、参加者から聞いたりして決めていきます。
    次回はプログラミング言語の歴史の予定です。
    ゆるくやっていくので、気軽にいきましょう!

    View full-size slide

  3. 第3回
    ゴーファーくんと学ぶ
    目的:AWSのサーバーレスの基礎を知り、
    今後使う機会に備えてもらう
    サーバーがないの?
    サーバーレスの世界

    View full-size slide

  4. 1. サーバーレス(Serverless)とは
    2. AWS Lambda (ラムダ)
    3. サーバーレス化のイメージ例
    4. サーバーレスで使うサービスなど
    5. AWSのサーバーレスのメリット
    6. AWSのサーバーレスのデメリット
    7. 考えられるサーバーレスの使いどころ
    8. 社内ハッカソンでやってみた
    9. サーバーレスで登場するワード
    10.参考:サーバーレス関係の商業本
    11.おまけ:XaaS話
    12.本日のまとめ
    のサーバーレスを知ってみよう

    View full-size slide

  5. 5
    1. サーバーレス(Serverless)とは
    ◆サーバーレス・コンピューティング(Serverless Computing)
    ◆サーバーがない、ではなくユーザー側は管理しなくてよい、意識しなくてよい。
    ◆物理サーバーはユーザー視点からは隠蔽、抽象化され、プラットフォーム側でマシ
    ンやリソースを動的に管理するという、クラウド・コンピューティングの実行モデル。
    ◆最初はGoogle App Engine(GAE)の2008年リリース。後にGCPの一部に。
    ◆本格開始はAWSのAWS Lambdaリリースから。2014(日本は2015)
    ◆2010年代半ばから世界で注目、一歩進んだクラウドの使い方としてトレンドに。
    ◆リフト&シフト(Lift & Shift)のシフトのほう。
    ◆AWS認定でも『デベロッパー – アソシエイト』始め上位資格でよく出題。
    ◆AWSでは、後述のAWS Lambda+マネージド/フルマネージドなサービス群で実現。
    https://aws.amazon.com/jp/serverless/
    ごーふぁー
    しすてむ
    AWSが管理する特製EC2的な基盤
    AWSが管理する特製コンテナ
    サーバーがないのかな? 見えないだけだった!
    ごーふぁー
    かんすう ゴーファーくんに
    見える範囲
    AWS Lambda
    デプロイ デプロイ
    !!
    ??
    2016 Google Cloud Functions 登場
    2016 Azure Functions 登場
    2016 ServerlessConf NYで開催

    View full-size slide

  6. 6
    2. AWS Lambda (ラムダ)
    ◆AWSのサーバーレス技術の中核
    ◆関数ベースの FaaS(Function as a Service)。Lambda関数単位でコードを書いて実
    行。開発者はコードに集中できる。
    ◆内部的にはFireCrackerという専用コンテナ上で実行、軽量のマイクロ仮想マシン
    が起動。コンテナ技術が使われているが、ユーザは一切意識しないのでサービス
    のカテゴリは[コンテナ]でなく[コンピューティング]扱い。
    ◆ユーザーが弄れるのはコード、メモリ割り当て(128MB-10240MB(10G))、IAM権限
    だけ。CPUはメモリに応じて自動で上昇。
    ◆コードを書ける:
    ◆コードの上げ方各種:管理コンソールの画面に直接書く/CloudFormationの設定ファイルの中
    に書く、ローカルからコードもしくは実行ファイルをアップロード/S3からアップロード、CI/CD
    環境のCodeCommitで管理されたコードからデプロイ...
    ◆各プログラム言語の機能+他のAWSサービスを呼ぶ+他のLambda関数を呼ぶ
    ◆なおLambdaはサーバーレス専用ではなく、サービス間を繋ぐ役割としてAWS全般で活用。
    ◆言語はJava, Go, PowerShell, Node.js(JS), C#, Python, Ruby。+カスタムランタイム
    https://it.impress.co.jp/articles/-/21998
    リクエスト数+実行時間で課金。
    実行時間は100ms→1ms単位に進化(2020)
    アイレットさんの本の試算より:
    1日1万リクエスト、128MBで約25円/月
    秒間10リクエスト1日86万で約2100円/月
    限界の1000リクエストで約6900円/月
    ギリシャ文字の11番目 大文字:Λ 小文字:λ
    数学の「ラムダ計算」が元らしい
    関数型プログラミングの用語で、JavaとC#にも
    「ラムダ式」がある
    サーバーレスの
    カテゴリーアイコン

    View full-size slide

  7. 7
    Webアプリケーション
    3. サーバーレス化のイメージ例
    AWS Cloud
    オンプレのWindows
    やLinuxマシン
    サーバーレスアーキテクチャーだと…
    フロントエンド
    側の画面
    バックエンド
    リクエスト
    受け取り
    いろいろ
    ロジック
    DB
    アクセス
    ファイル
    保存
    レスポン
    ス組立て
    認証
    いろいろ
    ロジック…
    セキュリ
    ティ
    CloudFront
    WAF
    セキュリ
    ティ
    S3 static website
    フロントエンド
    側の画面
    Cognito
    認証
    API Gateway
    リクエスト
    受け取り
    認証
    Lambda
    レスポン
    ス組立て
    DynamoDB RDS Aurora S3
    ファイル
    保存
    いろいろ
    ロジック
    EventBridge
    いろいろ
    ロジック…
    JSONやHTML
    JSON
    セキュリ
    ティ
    様々な
    サービス

    (画面の
    キャッシュ)
    VPC
    DB
    アクセス
    レスポン
    ス組立て
    イベント発生…
    Webサーバー
    Webサーバー

    View full-size slide

  8. 8
    4. サーバーレスで使うサービスなど
    ◆以下がよく登場する
    ◆API Gateway: APIコールの受け口。フルマネージド
    ◆Aurora Serverless: クラウド生まれのRDB。自動スケール、使わない期間は自動停
    止でコスト削減。v2が2022/4から使用可能に
    ◆DynamoDB: フルマネージドなNoSQLデータベース。Lambdaとセットで
    ◆CloudWatch: モニタリングの基本。Lambdaの実行ログもCloudWatch Logsに保
    存。EventBridge(CloudWatch Events)がイベント処理の起点
    ◆X-Ray: 分散構成のアプリの分析、デバッグ
    ◆SNS: 通知を他サービスへ繋げたりLambdaへファンアウトしたり
    ◆SQS: マネージドなキューイングサービス。Lambdaや他サービスと繋げる
    ◆CodeCommit/CodeBuild/CodeDeploy/CodePipeline: マネージドなCI/CD環境
    ◆S3: 容量無限、高耐久性のストレージ。ものは大抵ここに置く
    ◆Step Functions: ワークフロー。2020年から様々なサービスと統合が広がる
    ◆Cloud9: クラウド上で開発できるIDE
    ◆SAM(Serverless Application Model) / Serverless Framework: サーバーレス開発
    を助けるフレームワーク(ツール)。各種リソースの作成を自動化しサポート
    サーバーレス専用ではなく、EC2等で
    も普通に使うが、サーバーレスで特によ
    く使う、というサービスが多いです。
    非マネージド: OSレベルの設定、障害対応を自分で。EC2。
    マネージド: 管理運用がAWS側、自動でスケールなど。RDS, S3
    などPaaSな大半のサービスが該当。
    フルマネージド: さらにユーザー側のメンテ極少。DBのAurora,
    DynamoDB。 (保存領域も自動拡張する)
    クラウドで頻出。フルかの明確な違いは曖昧...?

    View full-size slide

  9. 9
    5. AWSのサーバーレスのメリット
    ◆①コスト大幅削減:
    ◆EC2:起動中ずっと課金。以前は1[H]→今は1[s]単位
    ◆サーバーレス:リクエストが来て動いた時だけ課金。以前は100[ms]→今は1[ms]単位
    ◆②スケーリング
    ◆EC2やDBのRDS:負荷に耐えるインスタンスを選んだり、Auto Scalingを設定したり。
    ◆サーバーレス:基本AWS任せで意識しなくてよい。可用性、回復性もあり心配事が減る。
    ◆③インフラに加えてOS,ミドルウェアのメンテ不要
    ◆EC2やRDS:Systems Managerを用いてパッチを当てたり、RDSも定期メンテで停止。
    ◆サーバーレス:不要。保守コストが下がる。
    ◆④手軽なアプリケーション実行
    ◆EC2など:IaaS系でインフラ構築時間は削減、ミドルウェア構築時間は必要
    ◆サーバーレス:ミドルの時間もなくなりその分を開発へ。サービスを組み合わせて手軽
    に動かせる
    ◆⑤セキュリティ
    ◆EC2: インスタンスが存在する限り脆弱性チェックや監視、メンテが必要
    ◆サーバーレス:Lambda関数は外部から攻撃できない。(API Gatewayは対応必要)
    Lambdaのコンテナ基盤には自動でパッチ適用される
    ◆⑥マイクロサービス(MicroServices)との親和性
    ◆サーバーレス:デプロイ単位で小さなサービスを作り相互に通信しあうMicroServices
    の考え方と、小さな単位のLambda関数+各種マネージドサービスの組み合わせがマッ

    サーバーレスの
    カテゴリーアイコン

    View full-size slide

  10. 10
    6. AWSのサーバーレスのデメリット
    ◆①Lambda仕様上の制約:
    ◆Lambdaはコールドスタートからの起動に100[ms]未満~1[s]以上。最長実行時間15分
    (当初は5分)。同時実行数上限1000。(申請可能)
    ◆小さな関数に分割して繋げるなど工夫がいる
    ◆②ステートレスな設計が必須:
    ◆Lambda関数にinが来る→処理→outは常に一定が必須。コンテナは“揮発性”
    ◆関数終了後もずっと状態を保持する、ファイルを貯めていくなどは仕組み上できない。
    ◆/tmpディレクトリの上限512MB。→ファイル保存は必ずS3を使う。
    ◆③サーバーレス流の監視が必要:
    ◆LambdaのSLAは99.95%。起動しなかったり2重起動した際の対応がいる。X-Rayなどで。
    ◆プロセス内の呼び出しでなくリモート呼び出しで分散的になる。
    ◆④向かない用途もある:
    ◆常にミリ秒単位の応答、24時間常時稼働など。コスト計算してEC2と計りに。
    ◆大きな1枚岩(モノリシック)のアプリケーションを分割できない場合は向かない。
    ◆Lambda+RDSがかつてはアンチパターン→RDS Proxyの登場で解決。
    ◆その他
    ◆OSは気にしなくて良いが、
    使う言語やライブラリのバージョン管理、更新は必要。
    ◆逆にOSやインスタンスのカスタマイズはできない。
    コールドスタート:コンテナ起動も含めた起動。その後は
    コンテナ終了までホットスタート(Lambda実行時間のみ)に。
    Provisioned Concurrency(2019)登場で改善。
    コンテナ起動ごとにRDSにコネクションを張るため
    上限を超えてよく枯渇した問題が解決。2020年が
    サーバーレス元年とのこと(有識者による)
    →特性を正しく
    理解して使う

    View full-size slide

  11. 11
    7. 考えられるサーバーレスの使いどころ
    ◆Good:
    ◆①必要な時期にむらのある用途
    ◆平日のみ、月初のみ使うシステムなど
    ◆②極力手間を減らして大事な開発にフォーカスしたい
    ◆少人数のスタートアップ企業、個人アイデアの素早い具現化、ハッカソンのような短期高速開発など
    ◆③サーバーのメンテとコスト料金削減
    ◆④フロントエンド中心の構成、バックエンドのシェイプアップ
    ◆JavaScript、JSフレームワークが注目されている理由のひとつは、このサーバーレスとの親和性
    ◆⑤負荷量や時期が予測できない用途
    ◆来週電撃公開のアイドル総選挙サイトなど
    ◆⑥スケーラブルで柔軟な構成を様々に工夫したい
    ◆S3+API Gataway+Lambda+DynamoDBならスケール対策もほぼ不要
    ◆一部だけサーバーレスも可能、様々なユースケースに対応可能
    ◆APIベース(API First)の開発、フロント側と独立して進められる
    ◆Bad?
    ◆①ミッションクリティカルな用途
    ◆銀行の高トランザクション、病院
    ◆②Lambdaの限界である15分を超える長いバッチ的処理
    ◆ 分割したり、Step Functions や AWS Batch へ
    ◆③24時間365日ずっとリクエストが来たり、高負荷で動き続ける用途
    ◆ EC2と変わらなくなってくる
    ◆④常にミリ秒単位の応答が必要な用途
    ◆コールドスタートがあるため。特にJavaは初回のJVM起動に時間が掛かるとのこと
    ◆なお機械学習系は、膨大な演算パワーが必要なのでEC2とのこと
    ◆CPUより強力なGPUを備えたEC2の専用インスタンスタイプが各種用意
    ◆そのEC2の上でコンテナを起動、中で演算したり

    View full-size slide

  12. 12
    8. 社内ハッカソンでやってみた
    ◆2021/2 @@@Hack Challenge 2021 Kチーム “チームKY”
    ◆『@@@@クローンをAWSサーバーレスで動かそう』
    ◆構成図などはそちらの資料参照
    ◆はまったところ
    ◆①Lambda関数からDynamoDBを検索する部分
    ◆想定した条件で検索できないかも...?→Lambda側でインデックス指定が不足、DynamoDB側
    でテーブル全属性を指定したインデックスを再作成で解決。
    ◆→NoSQL DBはRDBと思想が全く違う。RDB脳からの切り替え、テーブル設計が重要。
    ◆②S3静的ホスティング作成
    ◆バケットポリシー設定やCQRS設定が抜けてたりバケット名をtypoしてたり。
    ◆③API Gateway作成
    ◆APIキー作成や使用料プラン作成、CQRS有効化を忘れてたりしばらくはまる。
    ◆④Lambda関数作成
    ◆タイムアウト設定忘れ、IAM権限設定忘れ、レスポンスが変だと思ったら関数の途中でコケて
    た...など
    ◆→慣れない作業だと最初はある程度試行錯誤した。
    ◆掛かった時間
    ◆HTML+JSの画面コードをS3に移せるよう修正、計画立て、分担は事前に準備。
    ◆ハッカソンは2日間。2日目の朝にはもう動いた
    ◆→実工数3-4日ぐらいで3画面の検索系アプリを
    完全に違うアーキテクチャ上に移行!!
    サーバーレスだと
    開発に集中、かなり
    素早く実現可能。

    View full-size slide

  13. 13
    9. サーバーレス周りで登場するワード
    ◆①べき等性 (冪等性, idempotency, アイデムポテンシィ)
    ◆「ある操作を1 回行っても複数回行っても結果が同じである」こと。
    ◆登録処理を2回行っても正常終了、中間データは毎回削除してから実行など。
    ◆自動で起動するコンテナ→関数実行→コンテナ自動停止 の仕組みの上で動く
    Lambda関数には必要。
    ◆リトライが自動で行われたり、処理の単位が小さいため。
    ◆②ステートレス (stateless, statefulの逆)
    ◆処理や関数は中に状態を持てないし持ってはいけない。
    ◆リクエストが飛んで来たら前回の処理結果を元に分岐したりせず、そのAPIコール
    の入力情報だけで毎回処理。
    ◆③疎結合
    ◆小さな処理をする関数と小さな仕事をするサービスの組み合わせで実現。
    ◆それぞれの処理は互いに独立。クラウド設計の基本原則のひとつでもある。
    ◆マイクロサービスの考え方と似ているが、イコールではない。
    ◆EC2やオンプレマシンの1アプリの中に処理が凝縮された状態が、逆の密結合。
    ◆④イベント駆動、⑤非同期処理
    ◆ユーザが動画をアップロードしたらそこで一旦処理終了。別タイミングでエンコー
    ド処理を別関数が始めたり...
    ◆処理の順序が原則保証されない前提で設計したり。
    サーバーレス固有の
    特性を踏まえた設計を

    View full-size slide

  14. 14
    10. 参考:サーバーレス関係の商業本
    2020/07 2018/03 2018/03
    2017/10,
    2022/03
    海外の翻訳本
    コード: JS
    AWSJ社員の方の本
    コード: Python
    Lambdaにフォーカス
    最新の第2版登場
    コード: Python
    2021/06
    バックエンドにPython
    のFlaskを使う入門本。
    ちょい構成が不明?
    アイレットさんの本
    コード: Python,JS
    サーバーレスの歴史が分かる記事
    https://www.keisuke69.net/entry
    /2021/03/31/094707

    View full-size slide

  15. 15
    11.おまけ: XaaS話
    https://business.ntt-east.co.jp/content/cloudsolution/column-78.html
    https://customers-love-solutions.com/?p=784 の図を引用
    AWSなら
    EC2, VPC, EBS: IaaS
    DBのRDS, DynamoDB: PaaS
    S3: 単にストレージに使うならSaaS
    仕組みの中で使うならPaaS
    API Gateway、CloudFrontなど: PaaS
    Lambda: PaaS扱いだが別概念でFaaS
    下の図のようにPaaSの「アプリケーション」の四角
    をFunctionsとApplicationに細分化。
    PaaSを細分化したサブ分類がFaaS、と考えると
    説明がつきやすいかも?
    ◆AWSの各サービスが
    IaaS/PaaS/SaaSどこに属するかを
    きっちり考えるのは意味が薄そうです。
    ◆「サーバーレス」の概念そのものは、
    このXaaSの分類とは別軸で考えた方が
    よさそうです。
    →PaaSとFaaSなサービス群を組み合
    わせて実現、ぐらい?(諸説あり)

    View full-size slide

  16. 16
    12. 本日のまとめ
    ◆サーバーレスの考え方は2010年代半ばから実用化~2020年がサー
    バーレス元年!
    ◆EC2のような単に仮想サーバーを立てるよりも本格的なクラウドの使
    い方として、AWSも力を入れています。 AzureとGCPも。
    ◆AWSでは、Lambda中心+(フル)マネージドなサービス群で実現します。
    ◆正しく特性を理解し、うまく使えば大きな効果を発揮します。
    ◆後からサーバーレス構成にリファクタリング:可能だが手間
    ◆ゼロから構築する時:最初からサーバーレス構成で!
    Creative Commons Attributions 3.0
    The Gopher character is based on the Go mascot designed by Renée French.
    それではまた次回!
    Amazon Web Servicesロゴ、およびその他の AWS 商標は、米国その他の諸国におけるAmazon.com, Inc. またはその関連会社の商標です。
    わかってきたぞ

    View full-size slide