koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

30 MINUTES SISTERSでやりたかったこと～Zill O'll 青い死神カルラを見立てる～

プラモデル

30MSが発売されてからこのかた、新製品が発表されたら「どうせ買えない」発売したら「案の定買えない」でストレスが先行するのでまともに流通するまで期待値をゼロにすることにした。

最後にやりたかったことを少しやっておこうかと思って割高な新古のオプションパーツセットを買ってカスタマイズした。

3年前、発売前にはシミュレータでオプションパーツを組み合わせてみて「この見立てでキャラ作ってみるかなー」とか楽しんでいたのがピークだったように思える。

3年経ってみると、旧作本体こそある程度流通しているものの、肝心のオプションパーツは全く見かけない完全な企画倒れとなっていてがっかりだ。

自分はジルオールというゲームが好きで、そこには製作者の加護を受けているウルトラ中二要素満載ビキニアーマーという30MS向けのキャラがいるので「これは見立てておくか」と思っていた。これを3年越しにいくらかやった形になる。

大鎌ビキニアーマーで役割は密偵である。アホか？（褒めている）

とは言え、頑張ってオプション見繕うのもパーツの入手性含めて大変なのでティアーシャの手足とオプションパーツ、ヘアー、デカールを組み合わせた程度。色は先日トールギスをヅダに見立てたときの余りを使った。

最後にやっとこうってネガティブな動機だけれど、プラモを作るのは楽しい。

適当に組み合わせてみて少し色塗ればそれっぽいのができる。

30MLのコンセプトは最高かと思う。後はまともに生産流通させてくれ。理想は

だ！

アーマード・コア6も頼むぜほんと。コトブキヤから商品化の機会をガッツリもぎ取ったのだから、他のIP以上にファンに対する責任あるぞ！

そんな愛憎混ざった感情がバンダイにはあるのだった。

おしまい。

中小塩漬けWebサービスの今後とか、ソフトウェアのアップグレード戦略とか

雑記

※（株式会社はてなの）仕事ではなくプライベート方面の話

数年前位から中小規模のWebサービスってどうやって継続して行けばいいのだろう？　と考えている。

例えばこんな構成のサービス。

OSや言語、ライブラリのサポートが切れて久しいが、継続運用はしたい、しかしサポートされている環境にマイグレーションするほどの予算はない。そんな感じのやつ。

沢山あると思うんだよね。

コンピューティングをコンテナに塩漬けにして、永続化をマネージドサービスに移行して動けば低労力で継続運用可能にできる気はする。

例えばこんな感じの構成にする。

CDNを通して最低限のセキュリティを担保する形。マネージドファイアウォールも適用できれば上々。

こういうマイグレーションを商売にしているところも探せばある気はする。

しかし、何かしらコンテナ化を阻む要素があったり、永続化層に後方互換が保たれない要素があるとちょっと大変かもしれない。

予算が無い≒無茶ぶり、になりがちだろうし、そういう商売をやりたいかと言われるとやりたくない。

ITと関わっている限りはレガシー化して周辺環境がサポートされなくなっていく事は避けられない。

昨今は継続してアップグレードしやすい構成にしていく戦略が主流だろうと思う。自分が主体的に設計できるならそうしたい。

ただ、そうできないときの対応案も持っておきたい。

そんな感じ。

先日の記事はこの課題に対する一つの答えではあるけれど、予算がある大規模組織向けで、中小向けの戦略ではない。もっと泥臭いところを見た場合にどうするか？　の課題なのだ。

koudenpa.hatenablog.com

AzureというかMicrosoftの魅力というか強みというか

Azure

Microsoft Azureの強みが分からん、みたいな話をしばしば見かけるので、普段仕事ではAWSにロックインされているAzureにわかとしての認識をまとめておく。

まず、Azureはクラウドサービス単体で評価するものではない。自分はまあまあAzure推しだけれと、.NETと最適化されたIDEを採用しないならAzureではなく他のクラウドプロバイダを選択する。AzureはMicrosoftが抱える巨大なエコシステムの一部であり、単体では真価を発揮しない。

Azure ADでIDを管理し、Visual StudioでC#のアプリケーションを開発して、Azureで運用する。全てをMicrosoftにロックインされることで最大の効果を獲得できる。

ITサービスを開発運用するに当って必要な要素について、それぞれ最適ではなくとも、無難な選択肢になるものを広範囲に備えている。

  • OSへのログインとも統合できるID
  • .NETとそれを開発できるC#,F#
  • フルスタックのWebアプリケーションフレームワークASP.NET
  • 強力なORMのEntity Framework
  • これらの開発をフルサポートするVisual Studio
  • 開発物を管理、CI/CDを提供するGitHub
  • そして開発物を運用するAzure

Microsoftに強いITベンターはこれらの構成を前提に効率よく開発運用するノウハウを持っている。スキルセットが散らない利点がある。

また、安定した長期サポートを見込める点も大きい。特定のサービスを終了する際には年単位で猶予期間があり、しつこく何年何月には終了しますと案内がある。唐突にサービスを終了したり売ったりしない。

Windows Serverを10年サポートします。安心してください。のような時代は終わりを告げて、継続的なアップデートを求められるようにはなっているが、どのようにアップデートしていけばよいのかのサポートは手厚い。

learn.microsoft.com

アプリケーション面でも主流となるGUI開発フレームワークは基本的にはVisual Basicの延長線上にあり、時代に応じて進化している。途中で途切れてしまったものもあるが、Windows Forms,ASP.NET Web Forms,Blazorの流れに乗っていればいいだろう。

フレームワークの切り替えにはそれなりの労力が伴うが……

learn.microsoft.com

とは言え、1,2年で大きく潮目が変わるWebフロントエンドに追随していくよりは見積もりが立てやすいだろう。

ロックインされることで高い効率で開発運用を行え、他と比べて責任を負ってくれる範囲が広い。

Microsoftと数十年付き合ってきたところは特に縁切りする理由はないし、これからロックインされて安定した開発運用する選択もあるのだからそりゃ強いだろうと思う次第。

そんなわけで、Microsoftにロックインされるつもりのない人にはさほど魅力や強みがあるようには見えないのだろう。

きっかけになったつぶやき。

AWS Parameters and Secrets Lambda Extension vs AWS SDK

AWS

AWS SDKの圧勝。

特別な理由が無いならAWS Parameters and Secrets Lambda Extensionは用いず、AWS SDKなどで素直にSecrets ManagerやParameter StoreのAPIを呼び出した方が良い。

AWSのLambda関数からSecrets ManagerやParameter Storeの秘密情報を参照する際には、パフォーマンスやコスト面でハンドラ内で都度取得するのではなく、一度取得した値をキャッシュしておくことが望ましい。

これ行うためのLamda拡張機能が提供されている。

docs.aws.amazon.com

しかし、どうにもこの拡張機能が取り回ししづらい。自身でAWS SDKを用いるなどしてAPIを呼び出し、キャッシュした方が良いように思えた。

ざっと比較しておく。

以上！

*1:厳密にはSDKの方は任意だが、他の権限を使う必要性は薄い

Application Insightsのアップグレード体験はすこぶる良かった

Azure .NET

全てのサービスのアップグレードがこうであるといいのだけれどなぁ。のような気持ちとやったことのメモ記事。

.NET Core 3.1くらいのころからAzure App Serviceで動かしているアプリケーションがあるのだけれど、それは常にApplication Insightsとともにあった。

主には何かしら不測の出来事があった際に「何があったのか」を調べるのに使っているのだけれど、例外とその前後の出来事が分かりやすくてとても便利だ。

Application Insightsは大分前に世代が変わって、Azure Monitorと統合、アプリケーションからのAPIも大きく変わった。具体的にはOpenTeremetryベースになっている。

これに対応するには多少の作業が発生するのでサボっていたのだけれど、先ごろ観念して更新対応した。この際の体験がとても楽でよかったのでそのお気持ちを記録した次第。

こんな感じの案内がずっと出ているので流石に観念した

ぶっちゃけ「楽でした」で終わりなのだけれど、それだけではあんまりだろうと思うので、どういう感じだったのかをメモしておく。

なお、先に書いた通り.NET（ASP.NET Core）が対象なので、他の言語やフレームワークについては知らん模様。

対象=Azure の PaaS でのWebアプリケーションホスティングとのゆるい付き合い - koudenpaのブログ

  • Azure Monitorの中のApplication Insights
  • ワークスペース新規作成
  • サーバサイド修正
  • クライアントサイド修正
  • 軽微な更新作業で変わらない体験
  • オマケ: UseAzureMonitorは何をしているか？
続きを読む

Mackerelの式グラフで前日比とか先週比とかを眺める

Mackerel Tips

これ。

mackerel.io

仕事では負荷傾向を眺めるのに主にMackerelを使っている。

担当しているサービスはピークタイムの負荷傾向に曜日による差が結構ある。この時「何曜日の負荷が高いのかなぁ」のようなことを眺めたいと思ったときに、単にメトリクスの表示期間を1週間にすると、まさに見たいピークタイムの数値をいい感じに見ることができない（期間を長くするとメトリクスの数値が均されてしまう）。

そんな時にはカスタムダッシュボードに式グラフで1日前とか1週間前とかのメトリクスを重ねたグラフを配置して眺めている。

こんな感じに寄って見て、細かい数値で比較できる。

私用アカウントのものだが「3日前が相対的に負荷高めだったんだな」のようなことが視覚的に比較しやすい

式グラフの式は、特定のホストメトリックを一定期間ずつtimeShiftしてaliasをつけているだけ。

1dなら1日ズレる、7日ズラせば1週間分見られる。週ごとに見たいなら1wにすればよい。

group(
  alias(
    host(hostId,loadavg1), 'now'),
  alias(timeShift(
    host(hostId,loadavg1), 1d), '1d ago'), 
  alias(timeShift(
    host(hostId,loadavg1), 2d), '2d ago'), 
  alias(timeShift(
    host(hostId,loadavg1), 3d), '3d ago'), 
  alias(timeShift(
    host(hostId,loadavg1), 4d), '4d ago'), 
  alias(timeShift(
    host(hostId,loadavg1), 5d), '5d ago'), 
  alias(timeShift(
    host(hostId,loadavg1), 6d), '6d ago'), 
  alias(timeShift(
    host(hostId,loadavg1), 7d), '7d ago')
)

式グラフの使い方として、あるメトリクスをtimeShiftして重ねて表示するのは素朴に便利だと思う。

社内で「こんな風に見てる」って共有したら「へー便利（こういう使い方は）知らんかった（思いつかんかった）」って感じだったので、パブリックインターネットにメモした次第。

劇場版『ウマ娘 プリティーダービー 新時代の扉』

映画

ここ数年は毎年1本程度リピートしてこのブログに感想を書きたくなる映画があって、どうやら今年はそれが劇場版『ウマ娘 プリティーダービー 新時代の扉』であるようだった。

「今世紀最強のスポ根映画はこれに決まった」といった内容で最強だった。

この記事を書いている時点では2回しか観ていないが、特典が切り替わるたびに劇場に足を運ぶのだろう。

今のところの感想をざっくり記録しておく。

※普通にネタバレあります。

続きを読む