トップ > 社内イベント > 社内講演会レポート： サーバレスのアンチパターン

社内講演会レポート： サーバレスのアンチパターン

社内イベント クラウド（AWS）

こんにちは、ルナルナ開発の牧です。先日弊社にて、アマゾン ウェブ サービス ジャパン株式会社の西谷圭介さんに来て頂き、「サーバレスのアンチパターン」をテーマに講演会という形式でお話しして頂きました！

AWSの方のお話しを直接聞く機会があるなんて！これは行くしかない！と思った人は少なくなかったのでしょう。こんなに人が集まりました。

。。。そうです、写真を撮るのを忘れました。笑 でも50名以上の方が参加しましたよ！就職活動中の方々にもご参加頂きました！

恐縮ながら、代表して私が今回の講演会のレポートを書かせて頂きます。

発表内容レポート

サーバレスアーキテクチャの概要

前半はAWSを利用したサーバレスアーキテクチャの基本的なご説明でした。既存webバックエンドとサーバレスwebバックエンドの比較について下記に記載します。

traditional web backend

ベーシックな構成。カスタマイズ性が高い。知見がある人が多い。 しかし、スペックを意識して設計する必要。運用・コストも考慮が必要。

serverless web backend

全部awsでマネジメントができる。サーバの運用・スケールはawsに一任。 サービスの組み合わせだけで、セキュアなAPIアクセス制御などが実装できる。クライアント側の実装は従来と変わらない。 しかし、カスタマイズ性が低い。現状で知見がある人が少ない。

アンチパターン

たくさんのアンチパターンをご紹介頂きました！一部をご紹介します！ 「サーバレスをどうやって利用すればいいか」という観点で下記のレポートを読んだら面白いのではないでしょうか。

LambdaでRDBMS使いがち問題

  • Lambdaがスケールする、つまりファンクションのコンテナが大量に生成された場合に、各コンテナからDBへコネクションが貼られることになり、耐えられないケースが。また、VPC利用時のコールドスタートでは処理に時間がかかってしまう。
  • ◯DynamoDBを使おう！DynamoDBストリームは非同期に動作するので、Lambdaと相性がいい！

同期実行にこだわりすぎ問題

  • 同期でInvokeすると、同時実行数の制限に引っかかってしまいがち。
  • ◯ できるだけ非同期でinvokeしよう！レスポンスを毎回もらう必要だろうか？

サーバレスに夢見がち問題

  • サーバの管理は不要だが、運用は必要！
  • コスト効率が高いので、サーバを複数利用して実装するよりは安く済むが、リクエストが多い場合はそれなりのコストがかかる！また、複雑なことをやろうとすると、設計・開発コストが高くなる可能性が。
  • ◯ シンプルにできるとこは、サーバレスでシンプルに。

サーバレスで難しいことしがち問題

  • シンプルに使うことが、サーバレスの強みなのに。
  • ◯シンプルに使うべきものはシンプルに使いましょう。フルサーバレスにこだわらず、適材適所に使いましょう。

なんとなくVPC使いがち問題

  • VPCは必須ではない。使うのはVPC内のリソースにどうしてもアクセスする必要があるときだけ。必要でない限り使用しなくてよい。
  • ◯同期実行が必要な箇所や、コールドスタートする場面ではVPC使わないようにする。VPCのリソースとの通信が必要なのであれば非同期にする。

コールドスタート気にしすぎ問題

  • 安定的にトラフィックが発生している場合、コールドスタートに発生率は極小。
  • コールドスタートにかかる時間は、1年前と比べてかなり短くなっている。 ※それでも気になるなら、コールドスタートを速くするしか！

コールドスタートを速くするには

  • Lambdaファンクションに対してPingする。
    • 定期的にInvokeを行うことでコンテナが破棄されることを回避する。
  • コンピューティングリソースを増やす
    • コンピューティングリソースの割り当てを増やすことで初期化処理自体も速くなる。
  • ランタイムを変える！
    • JVMの起動は遅い。
  • VPCを使わない
    • DBの問題でどうしてもVPCを利用したい場合は、DynamoDBストリームを利用した非同期反映を検討。
  • パッケージサイズを小さくする
    • javaやめるなどを検討しても。POJOではなく、バイトストリームを使うなど。

IP固定したがり問題

  • API GatewayやLambdaから別システムや外部APIにアクセスする際のソースIPアドレスを固定したい。
  • IPを固定することは、スケーラビリティを捨てることに。
  • 実は日本固有の事情だったりするが。
  • LambdaではVPCを利用してNATインスタンスを使うという方法もなくはないが、VPCのコールドスタート問題や、自前のNATインスタンスの場合その可用性・信頼性・スケーラビリティを考慮する必要がある。

監視しなくていいと思ってる問題

  • Serverless != Monitorless
  • 処理の異常を検知して対応するのは、ユーザの仕事
  • ◯ CloudWatchのメトリクスを利用しよう！CloudWatch Logsへのログ出力とアラーム設定をすると監視しやすくなる。

おまけ

ローカルでテストしたい場合

  • Lambdaのランタイムをエミュレートする！Lambdaでは各ランタイムごとで使われているAMI(Amazon Linux AMI)を公開している。 ※使っているランタイムのバージョンも公開している。 ※内部的には標準的なコンテナ技術を使っている。

  • ツール

    • serverlessのようなローカルテスト機能をもったサードパーティ製フレームワークを利用する。
    • AWSで出していない、他のテストツールを使う。AWSではないので、動作の保証はできないが。

総じて

アンチパターンはなるべく避けよう。ただし、絶対悪ではない。いろんな事情で仕方ない場合もある。（IP固定されてるなど）できるだけ避けることを考えつつ、適当なところで手を打つのがいい。

感想

分かりやすくて、ずっと身を乗り出して聞いてしまいました。笑

最初にAWSに詳しくない人のために概要説明があり、アンチパターンの話も問題定義をしてから、なぜそれがアンチパターンなのか、どうすればそのアンチパターンを避けれるのか、アンチパターンを避けられないケースはどういうケースがあるのか、技術的観点で説明をするという流れで、すごい自分の興味を引き立たせられました！

「サーバレスに夢見がち問題」は、ぐさっときましたね。サーバレスは別にサーバがないわけではなくて、サーバを意識しなくてよいだけです。サーバレスを適材適所で利用して実装できる、そんなエンジニアになりたいものです。