mozyのかきおき

mozyの読書感想文や思考置き場

AWSの勉強会に行ってきた【サーバレス技術】

プログラミング テクノロジー 勉強会

【サポーターズCoLab勉強会】CTOが語るTalknoteを支えるサーバレス技術【AWS】

【サポーターズCoLab勉強会】CTOが語るTalknoteを支えるサーバレス技術【AWS】 - サポーターズCoLab
に行ってきたのでメモをシェアしておく

Talknoteとは

講師さんの作っているサービス LINEとか使ってる人が普通に使えるようにしている社内SNSとのこと。
チャット + コミュニケーションの可視化もできる

サーバーレスとは

  • BasS型 例: File base
  • FaaS型 例: AWS lambda
    などの種類があるが、今日はFaaSについて話す

種類

  • IaaS
  • CaaS Dockerとか
  • PaaS herokuみたいな グロースして行くとキツイ
  • FaaS アプリケーション部分がミニマム

サーバレスは何がいいのか メリットは

* コスト削減
* 局所化と疎結合
* スケーラビリティ
* イベントインテグレーション
  • インフラコスト削減
    • 待機分のサーバコストを削れるかも
    • 単位あたり 7割コストカットできた

  • 運用コスト節約

    • サーバ保守 サーバ管理とか、プロセス管理が容易
    • 偶有的な仕事の削減 (目的のためにたまたま発生する事象のこと)
    • プログラムのバグ潰しが減る
    • 本質的な仕事に取り掛かれるようになる
      • 本質的仕事とは、顧客の問題を解決すること 製品を差別化すること

  • サーバレスってなによ -> いわばシェアリングエコノミーかな

  • 局所化と疎結合が自然とできる

  • スケーラビリティ

    • 必要に応じて勝手にスケールする
    • 厳密な需要予測しなくていいのはナイス
    • タスク開始時点でサーバリソースの割合が保証される
    • スケールアウトについて設計考慮することが ::減る:: 。なくなりはしない。ボトルネックは外にあるので。
  • イベントインテグレーション
    • 様々なリリースのトリガーと簡単にリアルタイムに紐づけられる
    • IFFTTと概念は近い(？)

やってみたこと 実際の事例

* PDFプレビュー機能
* EC2 イメージマジックとゴーストスクリプトを走らせる
* cronで定期的に捜索してた
* メモリ食うので -> インフラコスト増
* いつPDFが来るかわからないのでwaitしている間のサーバコスト無駄

これは、Faas教科書みたいな案件とのこと

サーバレスの問題、リスクは？

  • ベンダー依存
    • ベンダーが定めた制限事項に仕様全体が限定される
    • APIのバージョンアップによって想定外の改修が起きる可能性
  • ベンダーロックイン
    • 特定のベンダーの仕様にシステム全体が依存してしまう
    • 特にFassはそう
  • 外部のボトルネックがある
    • サーバ上に状態を保持できないので外部サービスに渡す必要あり RDSなど
    • 無制限の自動スケールアウトなどは存在しない
  • 環境上の制約
    • 起動のレイテンシがある
    • 実行時間の制限
    • サーバーリソースの制限
      • 確保している分しか使えない
    • サーバ設定の制限
      • プリインのライブラリ、フォントファイルなど
        • ここは暗黙的に担保されるという思ってるけど意外と重要な点
      • 最近はラムダと同じDockerが落ちてるのでテストできるらしい
    • マルチテナント
      • セキュリティ面での問題がある可能性がある
      • EC2は専用ホストあるけど、lamdaはそうじゃないので気になる顧客もいる
  • 原子性の管理
    • 不可分性
    • それ以上細かい単位や要素に分割できない要素のこと
    • 共通のコンテキスト
    • 同じドメインモデルへの操作、同じDBテーブルへのアクセスなど、コレらをまとめて管理する手法がない

サーバレスとマイクロサービスの関係は？

サーバレスにすると必然的にマイクロサービスになる

メリット

  • 耐障害性
  • 変更に対する柔軟性
  • 技術多様性
  • ライフタイムを伸ばせる 長期的に伸びるために導入する必要あるだろう

デメリット

  • 整合性担保のためのコスト
  • 設計の複雑化
  • 運用コスト増

システムの複雑度を考慮した上で段階的に導入すべし

どんなときにつかうかの提案

  • プロトタイプ開発
    • 事例、お店に来た人をAIで解析マーケティング
    • 有効データとれるかわからないので、数店舗のみで実行
    • 実験的な取り組みとは相性いい
    • 大きくなっても構成変えなくて良いのはナイス
  • 予測が難しいトラフィック
    • 事例、ラウザでのカードゲーム
    • 10,000%トラフィックにも対応できた
  • データのフィルタ
    • UNIXという考え方 本を読むといい
    • 設計思想の定理に、割とマイクロサービスな考え方が詰まってる
    • 入力したデータを加工して出力する単機能プログラム grepなどの思想
  • サブドメインの分割
    • モノシリックで巨大なサービスを段階的にマイクロサービスに分割して行く
    • コアドメイン 最も重要で戦略的に必要な機能 (コミュニケーションに関する機能など)
    • 支援サブドメイン コアドメインを支援する独自機能 (ユーザ管理など)
    • 汎用サブドメイン 必要だが事業的に特別なでない機能 (認証 決済など)
      • ここからマイクロサービス化して行くべき

質疑応答

サーバレスとは、要するにサーバの外注ってこと?

違うぜ 意識しなくなるって意味
最初はBaasで君はアプリだけ作ればいいよーという文脈で始まったのもある

コストって抑えられるの？

コストは抑えられないかも。ここら辺のヘッジは難しい。
lamdaのファンクションで、ディスクエラーはつきもの容量とか。
冪等性担保は めんどくさいよね

結局サーバレスのいいところって？

人のコストは下げられるけど、お金のコストはかかるかも。
スケーラビリティの観点が一番大きい。
また、トラフィック対策の点も大きい。複製できるので逐次対応できる点が良い。