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

掲題の出来事の記録記事。

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

まぁまぁ紆余曲折しているので経緯も書いておく。

前提としてConoHaのVPSでWebサービスを動かしていて、RDB（実はMySQLでなくMariaDBだが……CentOS系なので）もVPS上で動かしている。

CoonHaのVPSは標準のストレージは50GB、任意で追加のSSDをアタッチできる。

• RDB運用とかしたくないし、マネージドDBを使おう
  • ConoHaには DBサーバー｜VPSならConoHa がある
• マネージドDB、スペックはともかく同時接続数が厳しくてリクエストを捌けない
• 仕方ないのでVPSでMariaDBを動かす
  • 50GBのディスクなんて使い切るわけないじゃん！！
• Mackerel がDBサーバのファイルシステム容量消費90%超のクリティカルアラートを通知してくる
  • 
  • 50GBのディスク使い切りそうじゃん……
• 仕方ないので追加SSDをアタッチしてRDBのデータをそちらに配置することにした

追加作業

ディスクの追加自体はConoHaのヘルプ（ 追加SSDの設定方法｜ConoHa VPSサポート ）の通り（例は ext4 だがCentOS7系だったので xfs にした程度）に、データディレクトリの移動は適当にググって出てきたページを雑多に参考にして処理した。

段取りの整理と、ミスした時のリカバリポイントを検討したかったので、スプレッドシートにやることを列挙してから作業した。

列挙した段取り

平時の運用でのバックアップ取得前にDBへのアクセスを打ち切ることで、作業が完全に失敗した場合でもまぁまぁ簡単に復旧したかった。それに頼ることはなかったけれど、使わないに越したことはない。

出来事

データディレクトリの設定を起動スクリプトスクリプト（ /etc/init.d/mysql ）内の datadir 変数値書き換えで行った。

さしあたってそれでデータディレクトリは切り替わったのだけれど、DBをアップデートしたら起動スクリプトも更新されてデフォルトに戻ってしまった。

設定ファイル（ /etc/my.cnf でインクルードしていた /etc/my.cnf.d に配置されていた server.cnf ）でデータディレクトリを指定するようにした。

これで大丈夫だろう。多分。

結果

4倍以上のディスク容量を得て色んな余裕が生まれた。

経過

追記。

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

— 光電/7474 (@koudenpa) August 23, 2019

この対応前後のIOPSのメトリクス

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

ASP.NET Core で System.Random を使う

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure CDNのTLS証明書設定は遅かった

この記事ははてな社内のLT会で使ったスライドを記事に手動でコンバートしたものです。

周りは割とディープなLTをしているなか、自分は『うへぇ、こんなに時間かかるのかよ』と言う感想の共有だけという薄さ。

それはそれでアリだと思っているのだけれど、インフラ畑の方の反応は『うんうん、そのくらいかかるよね』った感じで『これが経験値の差か』と思うなどしました。

そんなことがあった、と言う記録です。

---

Microsoft Azure に CDN がある

• 選べるプロバイダー
  • Verizon (S1)
  • Akamai (S2)
  • Microsoft (S3)
• 今回はこれには興味なし

Azure Content Delivery Network

Azure CDN に無償の証明書機能がある

• CDNのエンドポイントに向けたCNAMEレコードを作る
• 反映までに時間がかかると脅しがある
• どうせそんなに時間はかからんでしょ？

チュートリアル:Azure CDN カスタム ドメインで HTTPS を構成する

ドメイン名の検証後、カスタム ドメインの HTTPS 機能がアクティブになるまでに最大 6 ～ 8 時間がかかります。

最大 6 ～ 8 時間

実際に時間がかかった

• 23:48 設定完了済
• 08:31 証明書は発行済だが配置未完了
• 12:55 流石に完了

検証メールが届かない。寝るか。。。 pic.twitter.com/QM3NEDD4mz

— 光電/7474 (@koudenpa) May 28, 2019

（Azure）CDNを操作するときの心得

• 心と時間に余裕をもとう

Azure の PaaS でのWebアプリケーションホスティングとのゆるい付き合い

WebアプリケーションをMicrosoft Azure上のPaaSにホスティングしている。気が向いたのでどんな構成で付き合っているのか書く。

見出しは以下辺り。

• アプリケーションの構成
• 環境
• 監視など

一言で表すと『ASP.NET Core のアプリケーションを Visual Studio で何となく開発 App Service で何となく運用』している感じだ。

この『何となく』は大事で、難しいことを考えずにゆるくWebアプリケーションの開発運用と付き合えている。楽しい。

ひきこもりの思い出

世間でひきこもりが話題になっているので、少し自分について記録に残しておく。

以前少し書いたけれど、自分は中学生の頃から9年ほどひきこもりと言ってよい状態だった。 一応通信制の高校に在学していたけれど、その月一回の登校も行ったり行かなかったりだった。結果7年在学していた。高校4留である。趣味の買い物には出掛けていたけれど、おおむねひきこもっていたと思う。

その頃何を思っていたのか？　何分10年以上昔の話なので、定かな記憶はないし、良いようにねじ曲げて覚えているようなこともありそうだけれど、おぼろげには感覚が残っているうちに書いておこうといった感じだ。

経済状況

そこそこ長期のひきこもりができる位の経済力がある世帯だった。今はなき中流家庭ではなかろうか。趣味の買い物は主に祖父母からのお年玉などのお小遣いで行っていた。テレビゲームやガンプラ、マンガ、雑誌等の本程度で、浪費という程ではなかったように思う。

当時はこのままなにもしないでいても自分一人が衣食住を賄う位はどうにでもなるだろう。位に考えていたような気がする。

親のリタイヤ

お金はどうにでもなるという感覚はさほど的はずれではなかったはずで、親からもお金回りで苦言の類いを聞いた記憶はない。

ただ、お金はともかく寿命は順当に行けば親の方が先に尽きる。

「自分が死んだ後のことが心配でならない」

といったことを伝えられたことはあって、それなりの印象に残っている。

お金のことと同様に当時はあまり深く考えていた記憶がなくて『うぜーなー、知らんがな』位に捉えていた気がする。

家族とを含めて、現実との接点は希薄だったので、あまり実感がなかったのかもしれない。

余談だけれど、自分が物心ついた頃には祖父は退職していた。大手食品メーカーの工場に勤めていたそうなので、企業年金何かもそこそこ出ていたのではなかろうか。この頃の自分の趣味はそうしたお金に支えられていたのだろう。余裕のある時代だ。

手に職

明確な理由は全然覚えていないのだけれど、自分のお金を稼ぎたいと思った。漠然とした不安感からだろうか。何も覚えていない。

契機は一応の高校卒業だったはずだ。とは言え、卒業から手に職をつけようとするまでに半年は過ぎていた。

接客や肉体労働はやりたくなかったしできる気もしなかったので、多少覚えがあったパソコン操作を生かせそうなアルバイトに幾つか応募した。散々説教だけして不採用の連絡もしてこなかった広告作成会社の人事に非常な憎しみを覚えた。一生ゆるさんぞ。

全般に面接後の不採用の連絡はなかった気がする。都度採否を電話をかけて聞いてみじめな思いだった。

就活何十社落ちた、のような例とは規模が違うけれど、それなりに凹んでいたのだろう。今でいう情報商材のようなものにも引っ掛かりかけた。問い合わせを送ると即座に電話がかかってきて、まずx万円払え！　のようなことを言われるのだけれど、それを渋ると罵声が飛んでくる。ヤクザな商売である。

その後、運良く外資系のIT周りの派遣企業の募集に引っ掛かって、ソフトのデバッグや評価の仕事をできた。

月並みだけれど、自分でお金を稼げたのは嬉しかった。

ここで面接で説教を受け続けていたら、まだひきこもっていたかもしれない。運だ。

その後、職業訓練を受けてIT業界に潜り込んだ。まぁ、手に職がついたと言っていいだろう。頭と手が動くうちは仕事して給料を貰えそうな感覚がある。

親が死んでも生活力はともかく経済的には大丈夫、位の安心感はもってもらえたのではないかなぁ。と思っている。

オチ

ない。

他にも思い出はあるはずなのでボケる前に思い起こしてメモしていきたい。