御成門プログラマーの日記

Microsoft AzureやAngularなどの技術情報を発信します

AWS .NET Developer User Group 勉強会 #1 参加メモ

AWSのセミナーに参加してきたので備忘録がてらメモを公開します!!

f:id:tt-suzukiit:20190422210022j:plain

AWS .NET - UG について

ハッシュタグ #AWSDOTNET

AWS で作る Serverless ASP.NET Core 2.x WebApp はじめの一歩

まず"AWSは怖くないよ"

  • なぜサーバーレスなのか
    対義語 AWSだとVPC → なんでもできるけどじぶんでやらないといけない。サーバー管理も大変。柔軟なスケーリング。使った分だけ。

  • 必要なもの

    • AWSアカウント
    • VS2017
    • AWS Toolkit For visual studio←VSの拡張機能からインストール可能。
      • AWSのプロジェクトテンプレートが新たに出てくる。
      • サーバーレス→ASP.net core webapp
      • コマンドラインからでもデプロイ可能
  • アドレスはAPI Gateway → ステージから確認できる

  • 仕組み

    • AWS Cloud Formation WEBappを作るロールを作成する。

    • APIGateway インターネットのプロキシ

    • Lamda
      • インスタンスタイプはない
      • パフォーマンスを上げるにはメモリを多く割り当てる。
  • コスト

    • S3 無料
    • API Gateway 無料枠内
    • Lamda 無料枠内
    • Cloud Formation 無料
    • IAM 無料
  • はまりどころ

    • オートスケーリング

      • オートスケーリングするとクッキーが変わってしまう。
      • 回避策はS3にキーを共有でおいておく。これを対策するNuget-packageがある。
    • ファイルアップロード

      • HTTPリクエスト・レスポンスはJSON化されている。
      • バイナリファイルもテキスト扱いになってしまう。→API Gatewayの設定でバイナリメディアタイプを設定
    • 最大リクエストとレスポンスのサイズ

      • APIゲートウェイからラムダがJSON化したデータで最大6MBまで
      • 対策として大きなファイルはS3にアップロードする
        →署名付きオブジェクトURKを生成し、PUTする
    • タイムアウト時間

      • API Gatewayは最大タイムアウト時間は29秒まで
      • Lamdaは最大15分まで
    • デプロイ後のIAM Roleの権限に注意

      • デプロイ後はCloud Foumationが作ったI AM ROLEの権限になるのでデプロイ後に必要な権限を与えておく必要がある。
  • まとめ

    • SEVERLESSに向かないもの

      • RDBを使うもの
        • スケールしてしまうので最大同時接続数をコントールできない。
        • 制限できるけどサーバーレスのメリットがなくなる
      • VPCを使うものは、インターネットを超えるときにレイテンシーがある。タイムアウト時間29秒を超えてしまう。
    • 向いているもの

      • 使用頻度が少ないもの
        • そんなに使われない社内システムとか
      • 一時的なもの
      • RDB/VPCを使わないもの

True Cloud Native Batch Workflow for .NET with MicroBatchFramework

  • MicroBatchFramework

github.com

  • CLIツール作成フレームワーク

    • パラメータバインディング
    • .net汎用ホスト コンフィグの設定
    • .net core Global Toolsの対応
  • CloudNativeBat

    • コンテナ化ビリティの高さ
    • クラウドにどっぷり漬かることではない。マルチテナント化への対応
    • C# なら「.net core + Linux」これならどんな環境でも戦っていける。
  • FaaSとの比較

    • パラメーターバインディングはやってくれる。
    • SDK依存、ランタイムを通した実行などで動作が気になる。
    • 複雑な処理によるピタゴラスイッチ化には難あり。
  • AWS Batch + Fargateがお手軽

  • 最近はマルチクラウドなことが多い
    → Azure Dev OpsなどのCIに独特な方言を使いたくない.

  • Circle CIを選ぶ。
    circleci.com

    • モダンなシステム。日本でも流行。

    • ymalは基本コピペ

      • 認証情報はきっちり入れる必要がある。
  • サーバーレスの理想

    • インフラの面倒は見ない
    • SDKや実行環境の依存なく開発したい←これの思慮が欠けがち