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

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

Transcript

1. 先端技術勉強会 技術講習会 2022年6月 @iwasiman Advanced -STUDY GROUP- 第3回 ゴーファーくんと学ぶ AWSサーバーレスの世界 Technology TECH-SESSION
2. 2 この技術講習会(先端技術勉強会)について ⚫ 頻度は月１回?程度、基本1H。時間は夕方がよさそうです。 ⚫ とりあえず始めてみて様子を見ながら続けます。 ⚫ 今回もスライドで資料を作りましたが、Web上のリソースなどの参照が メインになる回もあるかもしれません。 ⚫ 説明中も適宜間を挟むので、リアクションはその都度音声でもチャット でもOKです! ⚫ テーマはフリー、参加者から聞いたりして決めていきます。 次回はプログラミング言語の歴史の予定です。 ゆるくやっていくので、気軽にいきましょう!
3. 第3回 ゴーファーくんと学ぶ 目的：AWSのサーバーレスの基礎を知り、 今後使う機会に備えてもらう サーバーがないの？ サーバーレスの世界
4. 1. サーバーレス(Serverless)とは 2. AWS Lambda （ラムダ） 3. サーバーレス化のイメージ例 4. サーバーレスで使うサービスなど 5. AWSのサーバーレスのメリット 6. AWSのサーバーレスのデメリット 7. 考えられるサーバーレスの使いどころ 8. 社内ハッカソンでやってみた 9. サーバーレスで登場するワード 10.参考：サーバーレス関係の商業本 11.おまけ：ＸａａＳ話 12.本日のまとめ のサーバーレスを知ってみよう
5. 5 1. サーバーレス(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が管理する特製ＥＣ２的な基盤 AWSが管理する特製コンテナ サーバーがないのかな? 見えないだけだった！ ごーふぁー かんすう ゴーファーくんに 見える範囲 AWS Lambda デプロイ デプロイ !! ?? 2016 Google Cloud Functions 登場 2016 Azure Functions 登場 2016 ServerlessConf ＮYで開催
6. 6 2. AWS Lambda （ラムダ） ◆AWSのサーバーレス技術の中核 ◆関数ベースの FaaS(Function as a Service)。Lambda関数単位でコードを書いて実 行。開発者はコードに集中できる。 ◆内部的にはFireCrackerという専用コンテナ上で実行、軽量のマイクロ仮想マシン が起動。コンテナ技術が使われているが、ユーザは一切意識しないのでサービス のカテゴリは［コンテナ］でなく［コンピューティング］扱い。 ◆ユーザーが弄れるのはコード、メモリ割り当て(128MB-10240MB(10G))、IAM権限 だけ。CPUはメモリに応じて自動で上昇。 ◆コードを書ける： ◆コードの上げ方各種：管理コンソールの画面に直接書く/CloudFormationの設定ファイルの中 に書く、ローカルからコードもしくは実行ファイルをアップロード/Ｓ３からアップロード、CI/CD 環境のCodeCommitで管理されたコードからデプロイ．．． ◆各プログラム言語の機能＋他のAWSサービスを呼ぶ＋他のLambda関数を呼ぶ ◆なおLambdaはサーバーレス専用ではなく、サービス間を繋ぐ役割としてAWS全般で活用。 ◆言語はJava, Go, PowerShell, Node.js(JS), C#, Python, Ruby。+カスタムランタイム https://it.impress.co.jp/articles/-/21998 リクエスト数＋実行時間で課金。 実行時間は１００ｍｓ→１ｍｓ単位に進化（２０２０） アイレットさんの本の試算より： １日1万リクエスト、１２８ＭＢで約２５円/月 秒間１０リクエスト１日86万で約2100円/月 限界の１０００リクエストで約６９００円/月 ギリシャ文字の１１番目 大文字:Λ 小文字:λ 数学の「ラムダ計算」が元らしい 関数型プログラミングの用語で、JavaとC#にも 「ラムダ式」がある サーバーレスの カテゴリーアイコン
7. 7 Webアプリケーション 3. サーバーレス化のイメージ例 AWS Cloud オンプレのWindows やLinuxマシン サーバーレスアーキテクチャーだと… フロントエンド 側の画面 バックエンド リクエスト 受け取り いろいろ ロジック ＤＢ アクセス ファイル 保存 レスポン ス組立て 認証 いろいろ ロジック… セキュリ ティ CloudFront WAF セキュリ ティ S3 static website フロントエンド 側の画面 Cognito 認証 API Gateway リクエスト 受け取り 認証 Lambda レスポン ス組立て DynamoDB RDS Aurora S3 ファイル 保存 いろいろ ロジック EventBridge いろいろ ロジック… JSONやＨＴＭＬ JSON セキュリ ティ 様々な サービス へ (画面の キャッシュ） VPC ＤＢ アクセス レスポン ス組立て イベント発生… Ｗｅｂサーバー Ｗｅｂサーバー
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。 (保存領域も自動拡張する) クラウドで頻出。フルかの明確な違いは曖昧．．．?
9. 9 5. AWSのサーバーレスのメリット ◆①コスト大幅削減： ◆EC2：起動中ずっと課金。以前は1[H]→今は1[s]単位 ◆サーバーレス：リクエストが来て動いた時だけ課金。以前は100[ms]→今は1[ms]単位 ◆②スケーリング ◆EC2やDBのRDS：負荷に耐えるインスタンスを選んだり、Auto Scalingを設定したり。 ◆サーバーレス：基本AWS任せで意識しなくてよい。可用性、回復性もあり心配事が減る。 ◆③インフラに加えてＯＳ，ミドルウェアのメンテ不要 ◆EC2やRDS：Systems Managerを用いてパッチを当てたり、RDSも定期メンテで停止。 ◆サーバーレス：不要。保守コストが下がる。 ◆④手軽なアプリケーション実行 ◆EC2など：IaaS系でインフラ構築時間は削減、ミドルウェア構築時間は必要 ◆サーバーレス：ミドルの時間もなくなりその分を開発へ。サービスを組み合わせて手軽 に動かせる ◆⑤セキュリティ ◆EC2： インスタンスが存在する限り脆弱性チェックや監視、メンテが必要 ◆サーバーレス：Lambda関数は外部から攻撃できない。(API Gatewayは対応必要) Lambdaのコンテナ基盤には自動でパッチ適用される ◆⑥マイクロサービス(MicroServices)との親和性 ◆サーバーレス：デプロイ単位で小さなサービスを作り相互に通信しあうMicroServices の考え方と、小さな単位のLambda関数＋各種マネージドサービスの組み合わせがマッ チ サーバーレスの カテゴリーアイコン
10. 10 6. AWSのサーバーレスのデメリット ◆①Lambda仕様上の制約： ◆Lambdaはコールドスタートからの起動に100[ｍｓ]未満～1[s]以上。最長実行時間15分 （当初は５分）。同時実行数上限1000。（申請可能） ◆小さな関数に分割して繋げるなど工夫がいる ◆②ステートレスな設計が必須： ◆Lambda関数にinが来る→処理→outは常に一定が必須。コンテナは“揮発性” ◆関数終了後もずっと状態を保持する、ファイルを貯めていくなどは仕組み上できない。 ◆/tmpディレクトリの上限512MB。→ファイル保存は必ずS3を使う。 ◆③サーバーレス流の監視が必要： ◆LambdaのSLAは99.95%。起動しなかったり2重起動した際の対応がいる。X-Rayなどで。 ◆プロセス内の呼び出しでなくリモート呼び出しで分散的になる。 ◆④向かない用途もある： ◆常にミリ秒単位の応答、24時間常時稼働など。コスト計算してＥＣ２と計りに。 ◆大きな1枚岩(モノリシック)のアプリケーションを分割できない場合は向かない。 ◆Lambda+RDSがかつてはアンチパターン→RDS Proxyの登場で解決。 ◆その他 ◆ＯＳは気にしなくて良いが、 使う言語やライブラリのバージョン管理、更新は必要。 ◆逆にＯＳやインスタンスのカスタマイズはできない。 コールドスタート：コンテナ起動も含めた起動。その後は コンテナ終了までホットスタート（Ｌａｍｂｄａ実行時間のみ）に。 Provisioned Concurrency(2019)登場で改善。 コンテナ起動ごとにＲＤＳにコネクションを張るため 上限を超えてよく枯渇した問題が解決。2020年が サーバーレス元年とのこと（有識者による） →特性を正しく 理解して使う
11. 11 7. 考えられるサーバーレスの使いどころ ◆Ｇｏｏｄ： ◆①必要な時期にむらのある用途 ◆平日のみ、月初のみ使うシステムなど ◆②極力手間を減らして大事な開発にフォーカスしたい ◆少人数のスタートアップ企業、個人アイデアの素早い具現化、ハッカソンのような短期高速開発など ◆③サーバーのメンテとコスト料金削減 ◆④フロントエンド中心の構成、バックエンドのシェイプアップ ◆ＪａｖａＳｃｒｉｐｔ、ＪＳフレームワークが注目されている理由のひとつは、このサーバーレスとの親和性 ◆⑤負荷量や時期が予測できない用途 ◆来週電撃公開のアイドル総選挙サイトなど ◆⑥スケーラブルで柔軟な構成を様々に工夫したい ◆S3+API Gataway+Lambda+DynamoDBならスケール対策もほぼ不要 ◆一部だけサーバーレスも可能、様々なユースケースに対応可能 ◆APIベース（API First）の開発、フロント側と独立して進められる ◆Ｂａｄ? ◆①ミッションクリティカルな用途 ◆銀行の高トランザクション、病院 ◆②Lambdaの限界である15分を超える長いバッチ的処理 ◆ 分割したり、Step Functions や AWS Batch へ ◆③24時間365日ずっとリクエストが来たり、高負荷で動き続ける用途 ◆ EC2と変わらなくなってくる ◆④常にミリ秒単位の応答が必要な用途 ◆コールドスタートがあるため。特にJavaは初回のJVM起動に時間が掛かるとのこと ◆なお機械学習系は、膨大な演算パワーが必要なのでEC2とのこと ◆ＣＰＵより強力なＧＰＵを備えたEC2の専用インスタンスタイプが各種用意 ◆そのEC2の上でコンテナを起動、中で演算したり
12. 12 8. 社内ハッカソンでやってみた ◆2021/2 @@@Hack Challenge 2021 Ｋチーム “チームＫＹ” ◆『@@@@クローンをＡＷＳサーバーレスで動かそう』 ◆構成図などはそちらの資料参照 ◆はまったところ ◆①Lambda関数からDynamoDBを検索する部分 ◆想定した条件で検索できないかも．．．?→Lambda側でインデックス指定が不足、DynamoDB側 でテーブル全属性を指定したインデックスを再作成で解決。 ◆→NoSQL DBはRDBと思想が全く違う。RDB脳からの切り替え、テーブル設計が重要。 ◆②S3静的ホスティング作成 ◆バケットポリシー設定やCQRS設定が抜けてたりバケット名をtypoしてたり。 ◆③API Gateway作成 ◆APIキー作成や使用料プラン作成、CQRS有効化を忘れてたりしばらくはまる。 ◆④Lambda関数作成 ◆タイムアウト設定忘れ、IAM権限設定忘れ、レスポンスが変だと思ったら関数の途中でコケて た．．.など ◆→慣れない作業だと最初はある程度試行錯誤した。 ◆掛かった時間 ◆HTML+JSの画面コードをS3に移せるよう修正、計画立て、分担は事前に準備。 ◆ハッカソンは２日間。２日目の朝にはもう動いた ◆→実工数3-4日ぐらいで３画面の検索系アプリを 完全に違うアーキテクチャ上に移行!! サーバーレスだと 開発に集中、かなり 素早く実現可能。
13. 13 9. サーバーレス周りで登場するワード ◆①べき等性 (冪等性, idempotency, アイデムポテンシィ) ◆「ある操作を1 回行っても複数回行っても結果が同じである」こと。 ◆登録処理を２回行っても正常終了、中間データは毎回削除してから実行など。 ◆自動で起動するコンテナ→関数実行→コンテナ自動停止 の仕組みの上で動く Lambda関数には必要。 ◆リトライが自動で行われたり、処理の単位が小さいため。 ◆②ステートレス (stateless, statefulの逆) ◆処理や関数は中に状態を持てないし持ってはいけない。 ◆リクエストが飛んで来たら前回の処理結果を元に分岐したりせず、そのAPIコール の入力情報だけで毎回処理。 ◆③疎結合 ◆小さな処理をする関数と小さな仕事をするサービスの組み合わせで実現。 ◆それぞれの処理は互いに独立。クラウド設計の基本原則のひとつでもある。 ◆マイクロサービスの考え方と似ているが、イコールではない。 ◆EC2やオンプレマシンの１アプリの中に処理が凝縮された状態が、逆の密結合。 ◆④イベント駆動、⑤非同期処理 ◆ユーザが動画をアップロードしたらそこで一旦処理終了。別タイミングでエンコー ド処理を別関数が始めたり．．． ◆処理の順序が原則保証されない前提で設計したり。 サーバーレス固有の 特性を踏まえた設計を
14. 14 10. 参考：サーバーレス関係の商業本 ２０２０/０７ ２０18/03 ２０18/03 ２０17/10, 2022/03 海外の翻訳本 コード: ＪＳ AWSJ社員の方の本 コード: Ｐｙｔｈｏｎ Ｌａｍｂｄａにフォーカス 最新の第２版登場 コード: Ｐｙｔｈｏｎ ２０２1/06 バックエンドにＰｙｔhon のＦｌａｓｋを使う入門本。 ちょい構成が不明? アイレットさんの本 コード: Ｐｙｔｈｏｎ，ＪＳ サーバーレスの歴史が分かる記事 https://www.keisuke69.net/entry /2021/03/31/094707
15. 15 11.おまけ: XaaS話 https://business.ntt-east.co.jp/content/cloudsolution/column-78.html https://customers-love-solutions.com/?p=784 の図を引用 AWSなら ＥＣ2, VPC, EBS： IaaS ＤＢのＲＤＳ, DynamoDB： ＰａａＳ Ｓ３： 単にストレージに使うならＳａａＳ 仕組みの中で使うならＰａａＳ ＡＰＩ Ｇａｔｅｗａｙ、ＣｌｏｕｄＦｒｏｎｔなど： ＰａａＳ Lambda： ＰａａＳ扱いだが別概念でＦａａＳ 下の図のようにＰａａＳの「アプリケーション」の四角 をFunctionsとＡｐｐｌｉｃａｔｉｏｎに細分化。 ＰａａＳを細分化したサブ分類がＦａａＳ、と考えると 説明がつきやすいかも? ◆ＡＷＳの各サービスが IaaS/PaaS/SaaSどこに属するかを きっちり考えるのは意味が薄そうです。 ◆「サーバーレス」の概念そのものは、 このＸａａＳの分類とは別軸で考えた方が よさそうです。 →ＰａａＳとＦａａＳなサービス群を組み合 わせて実現、ぐらい?（諸説あり）
16. 16 12. 本日のまとめ ◆サーバーレスの考え方は２０１０年代半ばから実用化～２０２０年がサー バーレス元年！ ◆ＥＣ２のような単に仮想サーバーを立てるよりも本格的なクラウドの使 い方として、ＡＷＳも力を入れています。 ＡｚｕｒｅとＧＣＰも。 ◆AWSでは、Ｌａｍｂｄａ中心＋（フル）マネージドなサービス群で実現します。 ◆正しく特性を理解し、うまく使えば大きな効果を発揮します。 ◆後からサーバーレス構成にリファクタリング：可能だが手間 ◆ゼロから構築する時：最初からサーバーレス構成で！ 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. またはその関連会社の商標です。 わかってきたぞ