Redashの初期設定が変わっていて？？？状態だった話

追記：変わっていたのではなく、参照する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日

---

AWSのEC2上に構築済みのAMIを使ってRedashを立てた。アクセスすると初期設定として管理者の情報を設定する画面が出てくるつもりでいたら、ログイン画面が出てきて？？？状態になった。

2020-02-21現在はそのような案内があったんだ！

• getting-started https://github.com/getredash/redash#getting-started
• のリンク先 https://redash.io/help/open-source/setup

が、実際には構築済みAMIを使った際にはすでに管理者は作成されていて、その情報がログに出力されているらしかった。

ログイン画面の右下に何やら怪しいリンクがある。

開くとそういった初期設定の情報が出てくる。

パスワードの見つけ方はここ、ってリンクがある。

https://docs.bitnami.com/aws/faq/get-started/find-credentials/

EC2ならAWSコンソールから起動ログ見られるよ！　と案内がある。これで僕はRedashにログインできました。

この記事が同じ混乱を得そうな人に届く可能性は限りなくゼロに近いけれど、事後にでも見つけて共感を得られたらニヤッとする。

それでは。

Webアプリケーションのキャパシティプラン

についてぼんやり考えていた。難しいな。と。

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ではないと考えている。

Azure担当大臣になれるかな

この記事には技術要素はありません。動作確認目的記事です（何の？　内緒）。

さて、狭い範囲で○○大臣、といった役割が任命されたり、自然発生したりすることがある。

たとえば、株式会社はてなには東京エンジニア大臣（正しくない名前かもしれない）（2名）がいたりする。東京オフィス勤務のエンジニア間の交流を盛り上げていく大臣だ。

さて、同社ではパブリッククラウドを活用しているが、ベンダーはAmazon Web Servicesに偏っている（その発信を探すとわかると思う。探すのが面倒くさかった）。

blogs.itmedia.co.jp

パブリッククラウドの世界的なシェアはこんな感じらしいのだけれど、社内でのMicrosoft Azureの活用具合はこのシェアほどではない。

僕はしばしばブログに記事を書くくらいにはAzureを気に入っているので、社内での存在感も高まると嬉しい。高まるためのアクションをしていたらAzure担当大臣になれるかな？

さーて、この記事は動作確認目的を達成するだろうか。

Azure記事の方が多い

Azure Logic Apps で epoch秒を得る

div(ticks(subtractFromTime(utcNow(), 1969, 'Year')), 10000000) こんな感じで得られる。特定の時刻のものが必要なら utcNow() の部分を適宜差し替えればいい。

使っている関数の詳細はリファレンス参照 式関数のリァレンス ガイド | Microsoft Docs。

現在時刻を得てから1970年からの経過時刻になるように1969年引いてからシリアル値を取得、秒の単位に切り捨てている。

MackerelのAPIは時刻をepoch秒で表現するのだけれど、これを簡単に得られない実行環境もあって、Azure Logic Apps（やMicrosoft Power Automateなど）はその一つだ。

↓の記事を書いたときにメモした記憶があったのだけれど、メモしてなかったのでメモした次第。記憶が全く当てにならない。どこか別の場所や記事に書いたのかもしれない。

koudenpa.hatenablog.com

AWS CDKでMackerelのAmazon EventBridge通知チャンネルのイベントバスとルールを作る

最近に MackerelのEventBridge通知チャンネル がリリースされたことで以下の目論見が完遂した。

koudenpa.hatenablog.com

どうせなら近々にMackerelの通知チャンネルに追加される予定のAmazon EventBridgeを起点にしようと考えた。すると、必然的にクラウドはAWSになる。そう言えば「Greengrassまともに使ったとこないな」とGreengrassにすることにした。リソースの管理をしたい。そう言えばCDKがC#対応していたのでC#にした。

そのAWS CDKでのEventBridgeのパートナーイベントソースからのメッセージを処理するリソース構築スニペット が以下。

ヘルプページ に案内がある AWSコンソールで連携設定をする の部分をCDKで構築する形だ。

var eventSourceName = $"aws.partner/mackerel.io/{props.OrganizationName}/{props.EventName}";

var mackerelAlertBus = new EventBus(this, "mackerel-alert-bus", new EventBusProps()
{
    EventSourceName = eventSourceName,
});

var mackerelAlertRule = new Rule(this, "mackerel-alert-rule", new RuleProps()
{
    EventBus = mackerelAlertBus,
    EventPattern = new EventPattern()
    {
        Account = new string[]{
            this.Account,
        },
    },
    Targets = new IRuleTarget[] {
        new LambdaFunction(cloudReceiveAlertFunction),
    },
});

全コードはGitHubリポジトリに放ってある。正直アラートを知らせるのにLED1つでは光量が足りていないので、もう少し工夫したいなぁ。と思っている。

github.com

---

追記：告知出ました。

mackerel.io

Blazor Server はウィザードで Azure App Service + SignalR Service にデプロイできてしまった他所感

Blazor WebAssembly を GitHub Actions で GitHub Pages に発行する - koudenpaのブログ ではBlazorの2種類のホスティングモデルのうち Blazor WebAssembly を GitHub Pages に配置した。もう一方のBlazor ServerはASP.NET Coreアプリケーションとしてホスティングする必要がある。そちらも試した。どうやったのかと所感を書いておく。

Blazor WebAssembly を GitHub Actions で GitHub Pages に発行する

koudenpa 2020 抱負 - koudenpaのブログ に書いた通り、C#でSPAを書ける ASP.NET Core Blazor に少し触れている。

Blazorはホスティングモデルが2種類あり、そのうち Blazor WebAssembly がいわゆるSPAで、サーバーで動作する機能に依存しないホスティングができる。Blazor Server は少々毛色が異なり、サーバーとSignalRで接続して協調動作する。

今回はこの Blazor WebAssembly を GitHub Pages に GitHub Actions で継続的にデリバリーしてみた。GitHubのみでリポジトリ管理からデプロイ、ホスティングが完結して非常にお手軽だ。

尚、2020年1月現在Blazor WebAssemblyはプレビュー版なので今後事情は変わってくると思われる。