[micronaut] micronautのLambda上での動作比較

Serverless いいですね! 環境周りの構築から解放され保守や運用の費用が大分抑えられますね。

Serverless のAWS上のLambdaの動作を確認してみます。

Micronaut上でそれぞれ、groovy, kotlin, kotlin w/ graalで測ってみたいと思います。

Micronaut は、 2.1.3 を利用してます。

groovy と、graal の組み合わせはできません。groovyのリフレクションに、graalVMが完全にサポートしてません。

実装は、簡単にJWTでログイン機能だけを有した処理で、groovy も、kotlinも同様の処理を実装してます。

Quarkus や、Helidon じゃなくて、なぜ Micronautなのか。それは、単純に Grails の知識があるので、Gormなどが使えるので学習が早そうだからです。
それにドキュメントも英語ですが、結構しっかり揃ってるのが良かったです。

kotlin と、 groovy は、 Java 11 (Corretto) で動かしました。
では、動作確認の結果です。

言語/イメージ 速度(cold) 速度(warm) メモリ(cold) メモリ(warm)
groovy 8415.87 ms 35.57 ms 205 MB 206 MB
kotlin 2718.67 ms 64.81 ms 181 MB 182 MB
kotlin w/ graal 342.15 ms 77.35 ms 172 MB 188 MB

cold と warm の差は cold は cold start で、lambda関数が最初に呼ばれる時です。
その後しばらく、warmの状態になっていて、呼び出しが早くなってます。

webアプリ的な観点でいうと、一番最初のlogin時は、cold start で時間がかかる。
その後の動作は、warm状態なので素早い。

しばらく放置してから、再度アプリを触ると遅くなる。という感じになると思います。

利用者から見ると、初回が遅くなるのでネットワークが悪いのかなと感じて携帯を大きく振って電波を拾うような行動を起こす。。。起こさないですし、携帯じゃなくて今はスマホです。

結果は、kotlin w/ graal がcold時のスタートが早いですね。
warm時は、実行毎に少し速度に上下がありますので、warmの結果は参考程度に。

groovyは、言語としては使いやすくてともていいのでチョイスしたいのですが、初回のlogin時だけちょっと時間がかかっても良いというなら選択肢としてはアリだと思いますね。
ただ、今回はとても小さいプログラムで試験したので、アプリケーションが大きくなった時はどうなるか心配はあります。

あと、graal ですが、ドキュメントみながら試行錯誤してやっていたのですが、メモリが10gないと、native-image が作成できなかったです。
CDの自動化の時は、どうするか悩み所ですね。

時間があったら、どのようなプログラムを作ったかも書いておきます。




ドコモ口座の不正に見る、旧日本軍との共通点

セブンペイの不正利用に続いて、今度はドコモ、金融・決済システムの不正悪用が続きく日本のシステムに不安を覚える人も多いと思います。

事件の詳細を知れば、なぜこんな幼稚で単純な不備が防げないのか、不思議だと思います。

システム開発の現場は一体どういうものなのか説明したいと思います。

まず、サービスが立ち上がるずっと前、そう企画時の段階です。

ここでは社内の優秀な方と、時には外部の優秀な方が集まり新サービスの構想、実現性を話し合ってます。

ここの段階で、不正利用、セキュリティなどの心配な部分については十分議論されてます。

しかし、ここで決定されたことは以降絶対後戻りしないのです。

これ以降の段階で問題点があって指摘をしても
「話を振り返すな!」
「偉い人が決めたことだから考えるな!」
「頭のいい人が決めたんだから間違いな」
と言う圧力があります。

A:「xxxxってやると、こう言う不正ができてしまいますよ」
担当者:「xxxつて対策してあるから」
A:「いや、その対策もこうするとダメですよ」
担当者:「そんなことまで誰もしないよ。xxx(偉い人)さんも承認してるから大丈夫だよ。」

こんな感じのやりとりになるのです。

ちなみに、もし問題が起きた時にそのxxx(偉い人)に聞くと
「なんで、そんな大事なことを俺にまでエスカレーションしないんだよ。話が出たらすぐに俺に報告しろ」
と返されます。

そして、以降設計、製造、テストの段階で問題に気付いても誰も相手にしません。

たまに外国の方が空気がわからずに指摘します。しかし可哀想に、日本的なやり方を説明しても本人は納得できずにずっと不満そうな顔して仕方なく付き合います。

簡単に言うと計画(企画)の段階で決めたことは絶対で、それ以降の段階の意見は絶対聞かない、振り返らないのです。

そう、なんだか知ってるような話ですね。

兵隊は優秀でも、指揮官が悪かったインパール作戦そのものです。

現場にいる人間がいくら訴えたも計画を絶対変えずにそのまま実行する。

下からの話は全然聞かずに、全ての責任を下になすりつける。

その結果はご存知の通りです。

実際に、私も最初の頃は色々と意見を言ったのですが上は絶対計画を変えません。

そうしてるうちに段々感覚が麻痺してきて、言っても無駄だ。とりあえず言われた事だけを完遂しよう。となるのです。

プロジェクト、組織全体が麻痺してくるのです。

これが伝統、形式美。

疑うだけ無駄なんですよ。

ちゃんと上手く行くように上の人が考えてくれているので、考えるだけ無駄ですよ。