ストレージを追加してから数日たったのでMackerelでメトリクスの変化を眺めた。
ディスクの負荷が元のディスクと追加ディスクに分散していた。
他のメトリクスはあんまり変化がなかったのでディスクI/Oの限界性能も上がって良かったねと言う感じ。 https://t.co/WIYbccujYI
— 光電/7474 (@koudenpa) August 23, 2019

f:id:koudenpa:20190903013137p:plain — この対応前後のIOPSのメトリクス

色んな余裕にはピークIO性能もありそうでよかった。

2019-08-12

ASP.NET Core で System.Random を使う

.NET Tips

ASP.NET Core （C#）で System.Random を使った際の覚書記事です。

アプリケーションを作っていると乱数を使いたくなる場面は多々ある。各言語では概ね疑似乱数の実装が提供されている。

.NET Core でも System.Random クラスが提供されている。

疑似乱数の生成器は内部に状態をもって、次々に疑似乱数値を生成していくものだ。したがって、疑似乱数クラスのインスタンスは乱数が欲しい場面ごとにインスタンスを生成するのではなく、使いまわしすることが望ましい。

これで済むのでは？

// シングルトンインスタンスとしてDIコンテナに登録
services.AddSingleton<Random>(new Random());

と思ったけれど、ドキュメントを読むとこんなことが書いてあった。

クラスRandomはスレッドセーフではありません。複数のスレッドRandomからメソッドを呼び出す場合は、次のセクションで説明するガイドラインに従ってください。

仕方ないのでガイドラインを参考にスレッドセーフになるようなRandomラッパーを書いて、それをDIコンテナに登録することにした。

// Randomのラッパーを作る。ここでは今回使うメソッドだけラップしている。
public interface IRandomizer
{
    int Next(int maxValue);
}
public class Randomizer : IRandomizer
{
    private Random random;
    private object syncRoot = new object();

    public Randomizer()
    {
        random = new Random();
    }

    public int Next(int maxValue)
    {
        lock (syncRoot)
        {
            return random.Next(maxValue);
        }
    }
}

// あとは Startup.cs でシングルトンに登録して
services.AddSingleton<IRandomizer>(new Randomizer());

// 使いたいところでコンストラクタインジェクションしてやればよい
public class HogeController : Controller
{
    private readonly ApplicationDbContext _context;
    private readonly IRandomizer _randomizer;
    public HogeController(
        ApplicationDbContext context,
        IRandomizer randomizer)
    {
        _context = context;
        _randomizer = randomizer;
    }
    // ...
}

パッと見動いていそうだった。

以下余談。

スレッドセーフなRandom実装を提供してくれれば楽なのだけれどなぁ。ConcurrentRandom のような感じで。

自分はC#とJavaをたまに比較するのだけれど、JavaではRandomの実装はスレッドセーフらしい。ただ、スレッドセーフにするためにそれなりにオーバヘッドがあるようで、それを回避するならスレッド毎に乱数を生成する実装を使うようするのがいいそうだ。

この事情はC#だろうが変わらないだろうけれど、今回はアプリケーション内で唯一の乱数生成器を使うことを優先した。

2019-08-09

リソース名を付ける時の名前長制限への対応

雑記 Tips

最近公私でいくつかリソース名の長さ制限に抵触する例が発生して面白かった。

ここでいうリソース名は、自分で長さの制御ができない接続先システムで一意にしたい名前だ。

一意な名前の作り方は幾つもあるけれど、以下のような場合が多いだろうか。

元々一意な値を使う
UUID を生成する
幾つかの名前を組み合わせる
- 環境名+システム名+リソースの種類・用途 など……

こうした何かしらの形で一意な値を作ったが、接続先システムのリソース名制限長がそれより短かったわけだ。

（最近はUUIDの文字列表現36文字は受け入れられることが多いけれど、そうではない場合もまぁある）

『私』の分では厳密に一意でなくてもどうにかなりそうな場面だったので、雑に超過した分を切り捨てて対応した。重複したらその時考えよう。

厳密に一意であって欲しい場合は『幾つかの名前を組み合わせる』の場合は命名規則を見直したり、『UUID』のように値が数値の場合は文字列表現を見直したりで対応していた。

Base64 エンコードはなかなか短くなる。使用する文字（特に記号）が名前に使えない場合はBase32なんて手法もある。16進数に比べたら断然短くなる。

どうにもならなくなった場合は、衝突可能性はあるものの適当にハッシュを計算して、Base32エンコードするとどうにか収まったりするのではなかろうか。

たまたまが重なって面白かったこの頃だった。

2019-08-03

ドラゴンクエストユア・ストーリーを観てきた

映画

僕はユアには含まれていなかった。

多少ネタバレがある、ネガティブな感情の吐露エントリーです。

ブログ記事にせずTwitterへのつぶやきだけで済ましておいても良いかなぁ、とも思ったのだけれど、ドラクエは好きだし、映画をみて感じた辛さは相当なものだったので記録に残しておこうと思った次第です。

koudenpaのブログ

趣味のブログです。職業柄IT関連の記事が多いと思います。

アイキャッチ画像がない記事をシェアした際、ブログタイトルや本文などから画像を自動生成する機能を試す記事

GitHub Actions で .NET Core の NuGet パッケージを Push した

Azure Functions （.NET Core）の DI 事情

ConoHa の VPS で動かしているMySQLのデータディレクトリを追加SSDに移動した

追加SSDを設けるまでの経緯

追加作業

出来事

結果

経過

ASP.NET Core で System.Random を使う

リソース名を付ける時の名前長制限への対応

ドラゴンクエストユア・ストーリーを観てきた