www.slideshare.net
これ、App Serviceで動くアプリケーションどうMackerelで見ようかなってこんな試行をして頓挫した身としてはとても嬉しいのだけれど、どうも表現されていない気がする。Blog記事くらいは書こう。フォント72ptくらいで『めでたい』とか書いとけば中身薄くてもいいだろ。https://t.co/m21x7JjlRM
— 光電/7474 (@koudenpa) 2020年3月13日
めでたい。
www.slideshare.net
これ、App Serviceで動くアプリケーションどうMackerelで見ようかなってこんな試行をして頓挫した身としてはとても嬉しいのだけれど、どうも表現されていない気がする。Blog記事くらいは書こう。フォント72ptくらいで『めでたい』とか書いとけば中身薄くてもいいだろ。https://t.co/m21x7JjlRM
— 光電/7474 (@koudenpa) 2020年3月13日
めでたい。
これは2020-03-11に株式会社はてな社内の共有スペースに書かれた内容の転載です。
昼会日誌の後東京地下(id:koudenpa は東京オフィスの地下で仕事をしている)でAzureを個人で(あんまりお金を払わずに)使うには? のような雑談をしていた。
結論から言うと『Azure Portalからリソースを作れば安心』。 リソースを作るときに月々幾らなのか? が見えるため。
koudenpaは無料(Free Tier)か完全従量課金のリソースだけ立て続けていて、月々Azureの利用料は100円前後。 AzureのコストをMackerelに送る、FunctionsとマネージドIDを使ってな - koudenpaのブログ のスクリーンショットはリアル。
(Visual Studioのサブスクリプションと一緒に課金されているので請求額やコストエクスプローラの額はそれが入ってる)
チュートリアルなどの『この構築済みソリューションをデプロイしてみよう』にはデプロイすると容赦無く月ン万円課金されるようなものも混ざっているので注意されたし。
(チュートリアルなどならちゃんと『最後に掃除しておきましょう』って書いてある(Azureはリソースグループを指定してグループ内のリソースを全部吹き飛ばせるので掃除は楽)けれど)
続きを読む僕はなぜMackerelにメトリクスを送ってしまうのか?
理由をこじつけてプログラムして、こんな関数アプリ( GitHub - 7474/PostAzureCostToMackerelFunction )ができ、こうなった。
追記: https://twitter.com/koudenpa/status/1236313266432823297?s=20
自分は『xxxを勉強する』だと全然身が入らないので『xxxをつかってyyyしてみる』でxxxを知ることにしている。
今回は『ARMテンプレートとマネージドID』を『AzureのコストをMackerelに投稿してみる』ことで知った感じ。
ついでにAzureのコスト管理APIも少し知れてよかった。
続きを読む昨今画像が性的だとか話題になっています。どの辺りから性的なのか、えっちなのかは見る人の主観によるところが大きいです。
これに対して、昨今では無限のクラウドの力で画像が性的かは簡単に判定することができます。
それが正しいかは不明ですがブレない判断ではあるでしょう。
ところで、僕は新世紀エヴァンゲリオンに登場するコンピュータ『MAGI』の作りが結構好きです。
NERV本部施設の運用やEVAシリーズのサポート、第3新東京市の市政に利用されている、スーパーコンピュータシステム。第7世代有機コンピュータとされる。メルキオール (MELCHIOR)、バルタザール (BALTHASAR)、カスパー (CASPER) という3つの独立したシステムによる合議制をとり[16]、人間の持つジレンマを再現している。
無限のクラウドには幾つかのプロバイダがあり、それぞれ画像が性的であるか? の判断を行えます。
というわけでMAGIに倣って合議してもらいました。
続きを読む追記:変わっていたのではなく、参照するAMIがカスタマイズされているものなだけだった。
https://redash.io/help/open-source/setup の手順を見て、 https://docs.bitnami.com/aws/faq/get-started/find-credentials/ のAMIを動かしている。アホか?
理由がわかってスッキリした。
神:
続きを読むAMI ってここにあるのを使いました?https://t.co/bHbfG22uK9
— Takuya Arita (@ariarijp) 2020年2月21日
についてぼんやり考えていた。難しいな。と。
WebアプリケーションのホスティングではだいたいCPUとメモリの所要量を見積もればいい感じがしている。これはだいぶ昔から変わっていない気がする。
(なお、ストレージI/Oはほとんどせず、他のホスト(DBや依存サービス)のリソースは十分である前提で無視!)
大体のWebアプリケーション実行環境では、並列実行数を指定できる。ある1回のリクエストに対するCPUとメモリ所要量と、ホスティングしている環境のCPUとメモリ量を元に並列実行数を指定すれば良い。
この際、メモリは若干悲観的に見積もった方が良い。メモリ消費が実装ないし割当量を越えるとリクエストが失敗(Out Of Memory系のエラー)したり、最悪の場合メモリスワップが発生して処理能力が大幅に落ちたりしてしまう。
CPUに関しては一瞬なら100%使用してしまっても、継続的に使用され続けなければ多少の処理遅延で済む。
これらの事情を考慮して、では自分が運用しているアプリケーションのある1回のCPUとメモリ所要量はどの程度のなのか、実行環境の並列実行数の指定はどうすればよいのか、を考えればよい。
実際の見積もり例はたまに見かけるのだけれど、改めて探すとすぐには見当たらなかった。
言うは易し、行うは難し、例がすぐ見つからないのは難しいからなのだろう。アプリケーションによって事情もだいぶ違うだろうしなぁ。などと思った。
余談として、FaaSではちょっと変わってくるはず。
AWS Lambdaではメモリだけ気にすれば概ねよいが、Azure Functionsではホスティングのプラン毎に考えることが変わる。コールドスタートの時間も厳しい(特にJavaや.NETなどは)し、現状はWebアプリケーションホスティングの第一選択肢はFaaSではないと考えている。
この記事には技術要素はありません。動作確認目的記事です(何の? 内緒)。
さて、狭い範囲で○○大臣、といった役割が任命されたり、自然発生したりすることがある。
たとえば、株式会社はてなには東京エンジニア大臣(正しくない名前かもしれない)(2名)がいたりする。東京オフィス勤務のエンジニア間の交流を盛り上げていく大臣だ。
さて、同社ではパブリッククラウドを活用しているが、ベンダーはAmazon Web Servicesに偏っている(その発信を探すとわかると思う。探すのが面倒くさかった)。
パブリッククラウドの世界的なシェアはこんな感じらしいのだけれど、社内でのMicrosoft Azureの活用具合はこのシェアほどではない。
僕はしばしばブログに記事を書くくらいにはAzureを気に入っているので、社内での存在感も高まると嬉しい。高まるためのアクションをしていたらAzure担当大臣になれるかな?
さーて、この記事は動作確認目的を達成するだろうか。