DEVGRU

プログラミングと競馬予想について書きます

(訂正あり) Serverless Framework で TypeScript を使うときは、aws-nodejs-typescript を使わずに serverless-plugin-typescript を使おう

(訂正)

書いたはいいが、 よくよく確認したら repository の last commit が2年前と全くメンテナンスされてない状態だったので、 こちらのほうがむしろ推奨されない方法となっていました。

なにかの参考になるかもしれないので、記事は残しておきます。

不便な記事2連発で申し訳ありません。

広告


tl; dr

sls create -t aws-nodejs-typescript -p プロジェクト名

あらまし

ちょっとしたスクレイピングをするバッチのために Serverless Framework + AWS Lambda + Node.js + TypeScript の構成で実装しようとしたが、 よく検索して出てくる方法が特定の方法に特化しすぎていて、使いづらいケースが多そうだったのでオフィシャルで説明されている方法をおすすめする。

検索するとよく出てくる方法

こちらこちらなどでは、以下のコマンドでテンプレートから生成する方法が紹介されている。

sls create -t aws-nodejs-typescript -p プロジェクト名

この方法で生成されるプロジェクトには以下の問題がある。

  • API Gateway 前提のコードになっていて、それ以外の用途で使いづらい
  • 依存が多い
  • serverless.yml ではなく serverless.ts になる

問題その1: API Gateway 前提のコードになっていて、それ以外の用途で使いづらい

生成されるコードはここの内容になる 1

github.com

見てほしいのは、 serverless.tssrc/ 以下で、どちらもガッツリAPI Gatewayを使用する設定になっている。

  provider: {
    name: 'aws',
    runtime: 'nodejs14.x',
    apiGateway: {
      minimumCompressionSize: 1024,
      shouldStartNameWithService: true,
    },
    environment: {
      AWS_NODEJS_CONNECTION_REUSE_ENABLED: '1',
    },
    lambdaHashingVersion: '20201221',
  },
const hello: ValidatedEventAPIGatewayProxyEvent<typeof schema> = async (event) => {
  return formatJSONResponse({
    message: `Hello ${event.body.name}, welcome to the exciting Serverless world!`,
    event,
  });
}

serverless.tshello ハンドラーがガッチリAPI Gateway使用を前提としているので、 それ以外で定時バッチ組みたいとかのケースだとこれらのコードを削除して整える必要があり、テンプレートを使う旨味が全然ない。

むしろ意図せずAPI Gatewayに公開する危険すらあるので、それ以外の用途で使う場合以外は使うべきではない。

問題その2: 依存が多い

Lambda は依存が増えるとパフォーマンスに影響が出るので依存を減らしたいところだが、 package.jsondependencies を見ると、@middysource-map-support が入っており、不要の場合いちいち削る必要がある。

また、その下の devDependencies は実行速度に影響こそないものの、なるべく少ないほうがパッケージのメンテナンス上都合がいい。

問題その3: serverless.yml ではなく serverless.ts になる

これは良し悪しだが、 serverless.ts はあんまり使いたくない。

スキーマチェックが入るので安心できる部分はあるが、ブログなどで紹介されている記述例は9割が serverless.yml なので、いちいち変換して書く必要があるのは美味しくない。

推奨する方法: serverless-plugin-typescript を使う

serverless-plugin-typescript を使おう。

github.com

serverless ではなく prisma-labs 以下のリポジトリなので 3rd party になってしまうが、 本家からも紹介されているので、 問題なく使えると思います。

使い方は、通常のプラグインのように npm install serverless-plugin-typescript したあとに、 serverless.yml に以下を追記するだけ。

plugins:
   - serverless-plugin-typescript

あとは、handler.js ではなく handler.ts に実装するだけで良い。

バンドラの設定などはよしなにやってくれる。

細かいところは ここ を参考にすると良い

まとめ

aws-nodejs-typescript よりも、 serverless-plugin-typescript を使いましょう。

AWS Lambda実践ガイド

AWS Lambda実践ガイド

プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発

プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発

  • 作者:Boris Cherny
  • 発売日: 2020/03/16
  • メディア: 単行本(ソフトカバー)


  1. プロジェクト謹製でこれなのは少し困る。

(お詫びと訂正)Android版COCOAがバグった理由

2021/02/06 21時35分 追記

参照したGoogleの資料が古く、現在はAppleと同じ仕様になっております。

先日報じられた不具合の原因はこちらのIssueと思われます。

訂正が遅くなり申し訳ありません。


調べたらそれっぽいのがわかったのでメモ。

広告


報道発表の時期から、原因はこのコミットだと思われる。

怪しいのはこの変更。

-                 MinimumRiskScore = 1,
+                MinimumRiskScore = 21,

(Minimum)RiskScore の定義を調べると、GoogleApple で異なる。

Appleの場合

https://docs-assets.developer.apple.com/published/7cd84254a3/rendered2x-1591113781.png

Google の場合

f:id:katoken-0215:20210203223636p:plain
https://www.blog.google/documents/68/Android_Exposure_Notification_API_documentation_v1.2.pdf

Apple は0~8の整数値を取る4つのパラメータの積で、0〜4096の値を取る。 それに対して、Google は 1〜8の値を取る4つのパレメータに更に重みを加味して正規化した、1〜8の値を取る。

そのため、RiskScore = 21 というのはApple 仕様の定義では適切だが、Google仕様ではありえない数値となる

結果として、iOSでは検知するがAndroidでは検知しないという状況が出来上がったと考えられる。

当たっているだろうか?

はじめてのAndroidプログラミング 第5版

はじめてのAndroidプログラミング 第5版

Ubuntu 20.04 (on Google Cloud Platform Compute Engine) で GPU サポートが有効な LightGBM をビルドする

サーバを作り直すときに調べたのでメモがてら。

公式に書き方は載っているが、記述が古いので掲題に特化した方法を載せる。

lightgbm.readthedocs.io

前提として、Compute Engine で GPU が有効なインスタンスがあり、そこに pyenv でPython 3.8.6がインストールされているものとする。

CUDA のインストール

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin
sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/11.2.0/local_installers/cuda-repo-ubuntu2004-11-2-local_11.2.0-460.27.04-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2004-11-2-local_11.2.0-460.27.04-1_amd64.deb
sudo apt-key add /var/cuda-repo-ubuntu2004-11-2-local/7fa2af80.pub
sudo apt-get update
sudo apt-get -y install cuda

ドライバーのインストール

必要なパッケージをインストールする

sudo apt update
sudo apt install --no-install-recommends nvidia-driver-390 nvidia-headless-390 nvidia-opencl-dev opencl-headers

以下のコマンドでインスタンスを再起動する。 SSH コネクションが切断されるが、30秒程度待つと再接続できるようになる。

sudo init 6

ビルドツールチェインのインストール

sudo apt-get install --no-install-recommends git cmake build-essential libboost-dev libboost-system-dev libboost-filesystem-dev

ソースコードのチェックアウトとビルド

git clone --recursive https://github.com/microsoft/LightGBM
cd LightGBM
mkdir build ; cd build
cmake -DUSE_GPU=1 -DOpenCL_LIBRARY=/usr/local/cuda/lib64/libOpenCL.so -DOpenCL_INCLUDE_DIR=/usr/local/cuda/include/ ..
make -j$(nproc)

Python パッケージのビルドとインストール

cd ../python-package
pip install setuptools numpy scipy scikit-learn wheel -U
python setup.py install --gpu

以上で、GPUが有効な lightgbm パッケージをインストールすることができた。

カテゴリ変数の数に影響があったりするので、気をつけること。