概要
実はSAAとSOAを最近取得できたのだが、構築経験に乏しすぎる耳年増なままDVAやらSAPを取っていくのは意味なさそうなので、色々経験を積んでいきたいと思う今日このごろ。
何かお題はないかと思っていたところ、こないだ作ったNetworkxでFF11のルート探索をするPythonプログラムがCLIベースだと微妙に使いにくいと思ったので、勉強がてらAWSパワーでウェブアプリにしてみることにした。
GitHub - bobfromjapan/FF11_route_finder
FF11のマップ移動が難しすぎるのでグラフ構造を使って解決してみる【NetworkX】 - 端の知識の備忘録
とりあえずまずは味気もなにもないHTMLテンプレートとFlaskを使ってローカルで動くようにしたところ、ちょうどAWSからApp Runnerなる新サービスが発表された。
どうやらBeanstalkのようにEC2やらなんやらが立つスタックとしてではなく、HerokuみたいなPaaSとしてコードと簡単な設定ファイルを書くだけでお気軽にWebアプリを走らせられるというサービスらしい。
あまりにもタイムリーすぎて運命的な何かを感じてしまったので、兎に角一回Flaskで作ったFF11ルート探索Webアプリ、FF11_route_finder ~online~
をApp runnerで動かしてみたというお話。
まとめ
- Webアプリ化はFlaskでやってみた
- これでフロントエンドも触ったことがあるということで、フルスタックエンジニアの仲間入りと言ってもいいかもしれない(冗談)
- App Runnerは素人でも簡単にWebアプリをデプロイできる使いやすいサービス
- GitHubにコードを上げておけばそこから勝手にPull→Buildしてくれるのはとても良い
- ロードバランサーやオートスケーリングも勝手に作られるが、正直今回の用途じゃ過剰過ぎるのでこれならHerokuの無料枠で十分かも
- お値段は最小構成(東京リージョン、1 vCPU $0.081 + 2GB RAM $0.009)で1時間$0.09。しかしリクエストを処理していないときはメモリ分の$0.009だけで済むらしいのでほぼ使われなければ月に700円程度。
- なんかのイタズラでオートスケーリングが発動するとデフォルトだと最大25台もインスタンスが動いてしまうぽいので、ちゃんと設定で減らしておくのをおすすめします。
App Runnerはお手軽で良いサービスなんだけども、やはり無料枠欲しいなあという感じ。誰も使わないであろうお遊びアプリで月700円取られるならビールを3本買ったほうがいいに決まっている。
ということで多分すぐ休止状態にしてしまうと思います。
こんな雑なアプリを公開状態にしておくのは怖いし。Flaskがレンダリングしてくれるものは対策してくれているらしいが、本当ならもうちょいちゃんとエスケープとか気にしなきゃならんのだろう。なにより、この辺の知識があやふやな私がお手軽PaaSで公開しているのは危ないだろうという判断である。
https://uh3dkqvvdz.ap-northeast-1.awsapprunner.com/uh3dkqvvdz.ap-northeast-1.awsapprunner.com
FF11_route_finder ~online~
使いたいという奇特な人はGitHubクローンして自分でローカルなりで動かしてください! コードはこちら
コードの更新部分
せっかくウェブアプリにするならば、ということで英語でも検索できる機能を追加してみた。
ヴァナ・ディールの地名の和英変換はFF11 Wikiのこちらの表から対訳表(auxfunc/dict.csv)を作成し、グラフを作成するためのyamlファイルの日本語地名を愚直に置換するスクリプトを書いて、英語用のyamlファイルを作成した。
FF11 Wikiは転載、改変自由というのはありがたいことである。
あとは出発地・目的地を入力するフォームや歩きのみで検索するかどうかの選択ボタン、和英選択のラジオボタンを配置しただけの簡単なHTMLテンプレートを作成し、Flaskの簡単なコーディングを行うだけ。その際こちらのサイトを参考にいたしました。
【Flask】formからサーバーサイドにテキストや各種コントロール、ファイルを渡す | たぬハック
ここまで作れば
cd path/to/app python application.py
を実行するだけでローカルで検索はできるようになる。お金もかからないし、正直ここまでで十分なはずであったのだが……。
App Runnerで動かしてみる
ほんとに前項のFlaskのコードを書き終えた日くらいにちょうどAWSからApp RunnerのGAがアナウンスされた。
いくつかApp Runner使ってみた系の記事はあったのだが、それらを見るまでもなくコンソールで言われたとおりにポチポチしていくだけで簡単にデプロイできてしまった。
書くほどのものではないのだが何枚かスクショを貼ってメモを書いておこう。
デプロイトリガーは手動を選択。自動デプロイは追加でお金がかかるようである(1 USD/アプリケーション、月額)
設定は別のファイルに記載しておくこともできるよう(App Runner configuration file examples - AWS App Runner)だが、今回はコンソールから設定することにした。
ランタイムは
Python
、構築コマンドはrequirements.txtを作っておいたので、pip install -r requirements.txt
でOK開始コマンドは初めてだったので若干詰まった。公式ドキュメントより、今回
application.py
がモジュール名なので、gunicorn application:app
とすれば良いらしいことがわかった。- ちなみにうまくApp Runnerが起動しない場合、15分くらいでエラーでロールバックが行われる。ステータスは
failed
になっていると設定項目の変更はできない(pause
またはrunning
でないとダメと言われる)ので、もうdeleteするしかなくなってしまった。
- ちなみにうまくApp Runnerが起動しない場合、15分くらいでエラーでロールバックが行われる。ステータスは
Running Gunicorn — Gunicorn 20.1.0 documentation
$ gunicorn [OPTIONS] [WSGI_APP] Where WSGI_APP is of the pattern $(MODULE_NAME):$(VARIABLE_NAME). The module name can be a full dotted path. The variable name refers to a WSGI callable that should be found in the specified module.
- 最後の
サービスを設定
ではAuto Scalingの設定だけ変更した。デフォルトだと最大25インスタンスまでスケールするようになっているので、万が一にでもDDoSを喰らおうものなら25倍もお金がかかってしまう。- Maxを1にしておけばリクエストが増えようがサービスは応答しなくなるだけで1台しか動かないはず。
ここまで設定すればあとは少し待つだけでWebアプリがAWSのどっかのサーバーで動いてインターネット経由でアクセスできるようになるわけである。
VPCもEC2もロードバランサーもRoute53も何も気にすることなくこれができるのはすごく魅力的。リクエストないときは最低限の課金というのもリーズナブルだし。App Runnerで費用・機能の要件を満たせるなら存分に使うべきサービスのような気がします。まあ会社じゃVPCでくくれない時点で使えなさそうなので私にとっては個人開発用ですね。
ただ、これだと楽すぎて正直なんの勉強にもならない!多分苦しみながらリソース建てたほうが何か得るものがあっただろうと思いました。
今後の展望
いつかは全体マップにルートの線書いたり、エリア別マップのリンクがついたりすると便利そうだなあと思っているがいつやるかはわからない。
あと、これならAmplifyとLambda、APIゲートウェイを合わせたほうがお安く済みそうだし、サーバーレスアーキテクチャの勉強になりそうなのでいつかはこっちも試してみたいと思います。