🪂

上昇気流を捉える8

2023/08/19に公開

Cloud

背景

前回からの続き。タイトルから強化学習がなくなっているけど続き

フライト中の判断ではなく、良いフライトや効率の良いフライトとはなんだろう？
上手い人はどのようなフライトをしているのか捉えやすくならないか？
ということを今更ながらに考えてフライト評価法を考えていたのに、サーバレスのコンテナサービスを比較していた。

作りたい物

IGCファイルを読み込みフライトを地図にマップ　　　　⚪︎
フライトの中でセンタリング（旋回）している部分を抽出　　△
センタリング中の上昇下降部分を色分け　　　　　　　⚪︎
センタリングの効率を計算　　　　　　　　　　　　　△
旋回中の風向を計算　　　　　　　　　　　　　　　　△
どこからでも使えるようにウェブアプリ化　　　　　　×

⚪︎；よくできました　
△；頑張りましょう　
×；もっともっと頑張りましょう

作ってみた

構想

ローカル環境でDockerコンテナでウェブアプリを開発して、最後にクラウドのコンテナのサーバレスにポンと置いてあとは分析三昧！

基盤的な部分

macbook air(M2) （学生の頃からの憧れで買っちまったが色々な苦労の始まり）
Docker （個人利用なのでDesktopも。M2でも使えた）
Django （Battery Includeでお気楽極楽。ローカルではそうだった）
PCはともかく、やりたい事だけ考えればありえる選択と思ってる

利用したライブラリ（特徴的と思うもの）

geopy(地図上に円を描画するための緯度経度情報を得る)
pyproj(緯度経度から距離を出す)
folium(地図描画作成)
simplekml(GoogleEarth用のKMLファイル作成)

『頑張りましょう』

センタリング（旋回）している部分を抽出.
指定秒数の間に今の進行方向と逆方向になっているポイントに場合にフラグを立てゆく。　
繋げるとセンタリング(旋回)している全てのポイントにフラグが立つが、普通に折り返しただけの部分にもフラグが立ってしまう。
センタリングの効率を計算.
上記のようにセンタリング以外にもフラグが立つので計ノイズが混ざる気がする、、
とはいえ下降したいのはランディングや激しく雲に吸上げられている時ぐらいなので多くないはず、としておく
旋回中の風向を計算
風向は場所や高度で変わるので、個々の旋回毎に計算したかったが、フラグの立った部分をきり分ける処理を思いつかなかった。が、これはなんとかなると思うのでそのうち改修しよう！

『もっともっと頑張りましょう』

どこからでも使えるようにウェブアプリ化
どのクラウドも「簡単にできる」風に紹介しているし、動確取れているコンテナ化したアプリはすでにあるし、個人情報扱うわけではないのでセキュアな環境が必要なわけではないのでこれまでより比較的簡単に、、、　と思ったがそんな簡単な話でなかった（そんな簡単ではないだろうと言う気はしていた）
WORA的な話にわかってても騙される感が、、

Azure (app service)

最終的に以下の流れでデプロイまで持って行けたとの理解。

githubにPUSH
CI/CDでAzureがビルド（以降は一連の流れ）
コンテナレジストリに登録される
app serviceのウェブアプリ、コンテナ使用の設定部分にデプロイ
外部からアクセスできる！

課題は以下

AzureDepOpsの入口にいつものAzureポータルから直接アクセスできずサービスに辿り着くのに時間がかかった
Djangoが素でサポートしているCSRFを解決するのに手間取ったもののやってみれはsettings.pyに設定を入れるだけだった
最初はローカルでビルドしたイメージを登録する方法を見ていたが、--platformオプションを入れてもうまく動く気配がなかった(python実行できてない、、)
ビルドする時のTagをlatestに固定しておかないとPullするときのTagが指定できない(なんとか出来るのかもしれないが見つからなかった)

最初に着手したので作業量的には最も大きくなってしまったが、これで以降の作業は目処をつけやすくなった

GCP (Cloud Run)

Azureと同じ流れと思いつつ結果は以下の理解。ちょっと違う

ローカル環境にgcloudをインストール
gcloudでログイン
ビルドしてレジストリに登録
cloud runがイメージをpullして実行
外部からアクセスできる！

Azureの時より容易に立ち上げることができた。サービスも作り込まれている気がする　
課題は以下

一度デプロイまで持ってゆかないとCSRFの設定を入れるためのアドレスがわからない
今は手動なのでこの後CI/CDの設定をしてGithubにあげたらデプロイまで進むようにしたい
とはいえ本当に手放しにするにはグーグルライブラリのインポートが必要そうでいやだ

AWS (App runner)

この時点で全く同じ機能のサイトが２つ立ち上がっている(動確取った非コンテナAzureWebApp含むと3つ)ので、これ以上する必要は全くない

aws上でapp runnerの設定を作成
githubにpush
PULLしてBuildしてDeployまで走る
外部からアクセスできる！

やるなAWS、と思ったもののAWSは最後まで動作させることができなかった。　
課題は以下

CSRFが(略)
guicornの起動指定(他サービスでは不要)、起動時の処理している(Dockerfileにある)が必要だった
AWSだけurllib3のバージョンを指定してrequirements.txtに記載する必要がある。そうしないとビルド時にエラーが出て先に進めない
コンテナログがとれず例外終了の内容を確認できない
他のサービスではタイムアウトしないがAWSではスペックを上げてもタイムアウトしてしまい原因がわからなかった

もっと調べれば、と思うもののすでに稼働しているサイトがあるのでその気になれなかった。一番安いプランで構築したAzureでも頑張って処理しているのにタイムアウトするって、、、

大雑把な比較

これまでの経緯からAzureに集約したいとも、運用していないので判断に必要な情報集まっていないとも思いつつ現時点での比較

コスト

ストレージを使ったAzureだけ固定費がかかっている。
GCPでNetworkingという費目があるがArtifactRegistryとやりとりしたから？
AWSはCloudWatchで課金が出たが、これは切り分けするためにログを出したからか？
どれもコストをサービス単位で出力できそうなのにサービス名と完全一致しないのは何故だ、、

Azure: サーバは無料プランなのでレジストリ、ストレージが課金されてゆく。数百円/月程度
GCP：　使用分のみ！
AWS：　使用分のみ！機能が動かないので使用しても目的は達成出来ない

パフォ

スペックはどれも必要に応じて変えることができると思うので決め手にならないかも

Azure: 起動が遅い！コールドスタートだと画面が返ってこないのではないかともうぐらい長い。一番安いタイプだからか、、
GCP: コールドスタートはAzureよりずっと早い。その後の処理は同じぐらい
AWS：コールドスタートはGCPと同じぐらい。そのあとはAppRunnerが落ちて502エラーが返ってくる

使い勝手

Azure: 最初の導入は色々あったものの、一度できてしまうと意識しなくなるので快適。作ってどんどんコミットするだけ
GCP: 今は手動だか多分Azureそれほど変わらないとこまで持って行けるのでは無いかと思う
AWS: Azureと同様。導入が早くできたので期待したがAWSだけの対応があるのが気に入らない

できたアプリの画面

同じ画面を表示するサイトが一時的に4件あった笑

この後

上昇気流を捉える話に戻る！

参考

情報共有に限りない賞賛と感謝を　
記事の登録日から現在までのギャップを埋める!

Azure

Githubからビルド、レジストリ登録のイメージ
 レジストリからWebAppまでのイメージ1
レジストリからWebAppまでのイメージ2

GCP

したかったことがそのままタイトルだった
 公式のページはちょっと分かってからみるとわかりやすい

AWS

個別の調整を除きほぼこの通りだった

判定処理など

当初の目的であったフライトの評価にこの辺りの知見を反映する予定、、
Soaring Engine
上昇気流の乗り方
 Hint of PraglidingHint of Pragliding
サーマル・フライング