雰囲気えんじにありんぐ

技術とゲームと本とその他書きたいことを書き散らすブログ

最近勢いを増してると噂の回転寿司「魚べい」に行ってみた【レポ】

概要

無性に回転寿司が食べたい。そんな時ありませんか?私にはあります。

というわけで大手3店くら・スシロー・はま寿司の店舗をGoogle Mapで探してみたんですが、どれも微妙な距離。色々加味して「今日は、はま寿司だ!」と意気込んだは良いものの、アプリを見ると7組待ちの文字。わざわざ混雑が少なそうな16時台に行こうとしてるんですけどね…。さすが日曜日、やるなあ。

しかし、はま寿司に行く気力がなくなっていたところで私は見つけました。「魚べい」の店舗を。そういえば最近、魚べいなる店が他店に負けじと売り上げを伸ばしているとの記事を読みました。私はこれまで魚べいには行ったことがありません。つまり、行くしかない!

店舗の様子

予約の方法を調べるのも手間だったので直接店舗までお邪魔しました。到着したのは17時過ぎくらいです。中に入ると何組か待っていたので、正面のパネルで整理券を取ろうとしたところで店員のお兄さんに「1名様ですね、〇番のカウンター席へどうぞ」と声を掛けられ札を渡されました。そうです、私は1人で行きました。寂しくなんかありません。

貰った番号札の席以外のカウンターが埋まっていたのでスムーズに着席。ただ、席までの案内をするか、もう少しわかりやすい場所に番号記載しておいてほしいですね。もし空席がいくつかあったらどれが自分の番号の席か迷ったのではないかと思います。

いざ、実食!

まあ、そんなことはさておき、結局は味なんですよ、顧客が求めているものは。

魚べいは回転寿司と言いつつ、皿が回転してません。注文オンリーです。これ私は正解だと思います。いつも回転寿司に行くたびに何分も流され続けてヨレヨレになった寿司を憐れんでいたので、最初から皿を流さない方針の方が廃棄も少なくて良いと思います。食べる分しか作らない。今の時代これで良いと思うのです。

早速、パネルから注文します。寿司のうまいまずいはマグロがわかりやすいと思ってます。普段はイカから食べたりしますが、今日はあえて「天然南まぐろ中トロ」「まぐろ」「活け〆かんぱち」をチョイス。中とろは1貫230円、まぐろは2貫1皿で130円、かんぱちは2貫1皿で120円(大多数がこの価格)です。さすが安いですね。あと汁物に「青さ汁」を注文。

5分くらい待ってレーンから注文した商品が届きました。

左からかんぱち、マグロ、中トロ。マグロは既に一貫食べてる。

まずはマグロから。パクリ。…うーん、冷たくてスジっぽい。130円クオリティ。正直あまり美味しくはないです。期待しすぎたかもしれません。100円ではない大衆寿司屋なら4倍くらいの値段で美味しいと思えるマグロが食べられます。私はそっちの方が良いですね。別に魚べいさんが特別悪いマグロを提供しているとかではなく、100円寿司でマグロを食べたことがある方なら一度は体験したであろう冷たさとスジっぽさです。

続いて中トロ。これはうん、美味しい。ちょっと中トロと呼ぶには脂が足りませんが、さっきのマグロより全然美味しいです。まあでも230円なんで妥当かな。

かんぱち、美味しい。特にコメントがなく普通に美味しいですね。ちょっと味を感じにくいですが、かんぱちってそういうもんみたいなところあるので。普通に美味しかったです。

ちょっとマグロにがっかりしながら青さ汁をかき混ぜます。なんだこの青さの少なさは。まあ青さ汁も120円なんで、そりゃ具材も少ないかと一人で納得しつつゴクリ。な、なんだこれは!!美味しい、美味しすぎる!なんだこの青さ汁めちゃめちゃ美味しいぞ!魚べいさんオリジナルである可能性は低いと思いますが、めちゃめちゃ美味しい!これで120円なら3杯くらい頼みたいです。お寿司を食べに来たつもりなので実際には頼みませんでしたが。

その他のネタも食べてみる

これだけで魚べいさんの評価を決めるわけにはいかないのでもちろん他にも注文します。上記と併せて個人的な感想を以下にまとめてみました。

商品 評価 値段 感想
中トロ 230円 値段相応に美味しい
活け〆かんぱち 120円 まあまあ美味しい
まぐろ 130円 冷たくてスジっぽいのでおすすめしない
青さ汁 120円 めちゃめちゃ美味しいので頼むべき
いか 120円 まあまあ美味しい
サーモン・焼きサーモン 120円 サーモンは微妙、焼きサーモンは美味しい
びん長まぐろ 120円 マグロと同じくちょっと…
えんがわ 120円 えんがわらしい脂を全然感じなかった
トリ貝・ホッキ貝 120円 1皿で2つの食感が楽しめて良かった
極上生うに 280円 期待以上に美味しかった
いくら 180円 期待以上に美味しかった

特に意外だったのが最後の方に頼んだ「生うに」です。1貫1皿280円と、他に比べてかなり高めの値段設定ですが、普通にうにを食べようと思ったらその倍はするので安いですね。届いた寿司も結構小さくてかわいらしかったんですが、味は美味しかったです。回転寿司のうにって大体薬っぽい味がして美味しくないので、あまり期待してませんでした。ただ結構強気の値段だったので試してみる気持ちで頼んだんですが、これは当たりですね。値段以上だと思います。

総評

私が食べた中だと、焼きサーモン・生うに・いくらあたりがおすすめです。そして忘れてはいけないのが青さ汁。マグロの類は値段もっと上げてでも頑張ってほしいなと思いました。

合計約1700円で寿司が食べれて満足です。魚べいさん、ごちそうさまでした。

プロセカの課金が止まらないのでガチャ別にコスパを考えてみる

概要

プロジェクトセカイというアプリをご存じでしょうか。初音ミクなどのVOCAROIDやオリジナルキャラクター達が登場する、巷で地味に流行り続けている音ゲーです。

私は普段スマホゲームのアンチみたいなところがありますが、このゲームは結構ハマってます。昔Shadowverse (通称シャドバ)というカードゲームにハマった以来です。時間だけで比較すると圧倒的にシャドバの方がプレイしていますが、課金額では圧倒的にプロセカの方が投入しています。大学生から社会人になった影響も大きいですが、課金額が増え続けている事実は受け止めなければいけません。

ま、課金してはいけないとか、そんなのわかってるんやけどな。課金することで日中に社会に飲まれて植え付けられたストレスを消化する一助になっているため、課金自体を無くすスタンスはとりません。あくまでコスパの良い課金・ガチャ方法を検討したいと思います。

推し

課金種別

コスパの良い課金方法は検討するまでもなく以下です。

  • プレミアムミッションパス 1800個
  • カラフルパス 450個

上記は月に1度しか購入できず、普段からガチャを引くには足りないです。そのため通常のクリスタル購入で最もコスパが良いのは1万円で10500個購入する方法でしょう。また、周年や年末等イベントで特別な課金方法が登場することがあります。こういったときに忘れずまとめて課金することも大事です。

といったわけで、課金方法についてはこれ以上コスパの良い方法はありません。となると課金額をできるだけ抑えるには「どのガチャを引くか」が大事になります。

ガチャ種別

ガチャには以下の種類があります。

  1. 恒常ガチャ
  2. 限定ガチャ
  3. セレクトガチャ
  4. カラフェスガチャ

恒常ガチャ

通常ガチャです。☆4確率は3%と他のゲームに比べると結構高いです。恒常ガチャを引く方法には以下があります。

  1. 有償クリスタル100個 1日2回
  2. 有償クリスタル1500個 10連 1回のみ
  3. クリスタル3000個 10連

これに加えて通常ガチャでは天井とシールが存在します。天井はガチャボーナスと呼び、ボーナス50で☆4確定、ボーナス100でピックアップ確定です。無償クリスタルで引くと1回0.5貯まりますが、有償クリスタルだと1回1貯まります。さらにシールは1回1枚入手でき、300枚でピックアップと交換できます。ややこしいですね。

1のパターン

通常ガチャの期間が仮に10日あるとすれば、ガチャは20回2000個で引くことができます。☆4が1枚以上出る確率は1-0.97^20 = 45.62%です。ガチャボーナスは20貯まり、シールは20枚入手できます。しかし天井や交換には他のガチャでの補填が必要です。

2のパターン

1500個で10連なので明らかにパターン1よりコスパが悪いです。なお☆4が1枚以上出る確率は26.26%です。しかし無償の半分で引けるため、パターン3よりはコスパが良いです。1と2を併せると3500個で30連ひけて59.9%です。うーん、微妙ですね。

3のパターン

確率的には8割以上を目指したいところ。とすると必然的にこのパターンでも引く必要が出てきます。80%の確率で☆4を手に入れるには53回引く必要があるため、23回6900個の準備が必要です。またその場合ボーナスは11.5、シールは23枚入手できます。しかしボーナスが累計50いっていないので勿体ないですね。ボーナスを考慮するなら30回引くべきでしょう。30回引いた場合には☆4が出る確率は83.92%になります。

上記全て併せると☆4を80%以上の確率で引く場合には

  • 必要クリスタル:有償3500個、無償9000個
  • 入手ボーナス:50
  • 入手シール:60枚

といった結果になります。うちボーナスで☆4確定が1回あるため、2枚入手できる可能性が高いでしょう。60連で2枚以上当たる確率は54.08%なので、運によっては3枚入手もあります。

限定ガチャ

限定ガチャの確率は恒常と変わりません。単にボーナスがありません。そのため恒常のように無理にボーナスにあわせてガチャを引く回数を調整する必要はありません。計算するまでもなくコスパは最悪です。引いてはいけません。

セレクトガチャ

1回しか引けませんが、有償3000個でセレクトした☆4が1枚確定です。恒常や限定では100%引く確率など計算できないため確定というだけでコスパは最高です。引くべき。

カラフェスガチャ

厄介なのがこのカラフェス。カラフェスでは☆4確率が2倍、つまり6%になります。またフェス限定の☆4がこの期間中のみ放出されます。カラフェスの期間は短いので有償100個のガチャは10回がせいぜいでしょう。

  • 有償100個 1日2回:10回引いて46.14%
  • 有償1500個:46.14%

上記2つ併せると20連で70.99%となります。この時点でかなり高い確率で☆4を引けますね。無償ガチャ10連と併せて30回引いた場合☆4を1枚以上引く確率は84.37%となり

  • 0枚引く確率:15.63%
  • 1枚引く確率:29.92%
  • 2枚引く確率:27.69%
  • 3枚引く確率:16.50%

となります。2枚以上当たる確率は54.45%あるため、人によってはセレクトガチャよりコスパが高いでしょう。

何を引くべきか

課金前提で話します。今更か。

セレクトガチャは必須。その他はカラフェス優先しつつ、余裕があれば恒常・限定の有償100個1日2回を引き続けるのがコスパ高いですね。この場合、100個100円とすると6000円+プレミアムミッションパス2000円+カラフルパス500円で毎月8500円の課金です。

これほど課金できない場合はミッションパスとカラフルパスのみ購入がおすすめ。

さらに課金できる場合、1500個10連を引くべき。イベントが月に3回あったとして、通常2回限定1回であればボーナスも考えて

  • 通常1:有償3500個+有償無償9000個
  • 通常2:有償3500個+有償無償9000個
  • 限定:有償3500個

仮に全部有償なら28500円です。

しかし、ここで大きな問題が生じます。それは限定ガチャを殆ど引けないことです。これは困ります。なぜなら限定ガチャは恒常と違い、イベント期間中を逃すと1年後の復刻しか引けるタイミングがありません。また復刻を逃すと一生引けない可能性もあります。したがって限定ガチャは必須で引かなければなりません。

限定で3枚ピックアップされるとすると全て引き当てるには天井になりシール交換する可能性が高いです。つべこべ言わず天井まで引きましょう。300連の天井には3000個×28回=84000円の補填が必要です。ちなみに3%のガチャを300連する場合、79.74%の確率で7枚以上引くことができます。

結論

ガチャは引きたいときに引こうね。

Terraform Moduleを使ったAzureリソースの管理方法を考えてみる

Terraform Moduleとは

Terraform Moduleを使うことで、同じリソースを複数作成する際に、変更したいパラメータだけを記述して簡単にリソースを作成できます。詳細については以下の記事が役立ちました。

今回はAzureを対象に構成を検討してみました。Terraformの構成はシステムごとにベストプラクティスが異なるため、あくまで一例としてご参考ください。

全体構成

terraform-azure
│   .gitignore
│   README.md
│
├───environments
│   ├───dev
│   │        main.tf  ... シンボリックリンク
│   │        providers.tf  ... シンボリックリンク
│   │        terraform.tfvars
│   │        variables.tf  ... シンボリックリンク
│   │
│   ├───prod
│   │       main.tf  ... シンボリックリンク
│   │       providers.tf  ... シンボリックリンク
│   │       terraform.tfvars
│   │       variables.tf  ... シンボリックリンク
│   │
│   └───stg
│           main.tf  ... シンボリックリンク
│           providers.tf  ... シンボリックリンク
│           terraform.tfvars
│           variables.tf  ... シンボリックリンク
│
└───shared
    │   main.tf
    │   providers.tf
    │   variables.tf
    │
    └───modules
        ├───management
        │       main.tf
        │       output.tf
        │       variables.tf
        │
        ├───network
        ├───security
        └───vm

モジュールがshared/modules、それを呼び出すルートがenvironmentsです。ルートは環境ごとに管理したいためenvironment/devのようにdev/stg/prodでそれぞれディレクトリを用意しています。

Terraformでは環境の分け方としてディレクトリの他にもWorkspaceを使う方法がありますのでお好みで。

environments

ルート側のファイルは4つありますが、実はそのうち3つが共通の記述で使えるため、shared配下にあるファイルのシンボリックリンクにしています。

  • main.tf ... 作成したいリソースを記載する。主な変更箇所。
  • providers.tf ... azurermのversion等を記載する。変更しない。
  • variables.tf ... 以下のtfvarsに記載する変数を記述する。環境ごとに変わらない。
  • terraform.tfvars ... 環境ごとに異なる変数を記載する。シンボリックリンクでない唯一のファイル。
environments/main.tf
locals {
    resource_group_name_test = "rg-${var.env_name}-test"
    resource_group_name_test2 = "rg-${var.env_name}-test2"
}

# TEST用のRG
module "management" {
    source = "../../shared/modules/management"
    resource_group_name = local.resource_group_name_test
}

# TEST用のRGその2
module "management2" {
    source = "../../shared/modules/management"
    resource_group_name = local.resource_group_name_test2
}

main.tfでは実際に作成するリソースを記述します。上記の例ではモジュール../../shared/modules/managementを呼び出しています。これはリソースグループのモジュールです。managementとmanagement2で2回呼び出しているためRGが2つ作成されます。

environments/variables.tf
variable "env_name" {
    type = string
    description = "環境名"
}

env_nameは環境ごとに値を変えたいためvariablesに記載しています。具体的な値はtfvarsに記載します。

environments/terraform.tfvars
env_name = "dev"

modules

shared/modulesにモジュールを記載します。今回は検証のためにmanagementモジュールだけを作成します。

  • main.tf ... モジュールを記載する。
  • output.tf ... 他のリソースで呼び出したいouputを記載します。今回はなし。
  • variables.tf ... environments/main.tfで呼び出す変数を記載します。中にはdefaultの値を記載している変数もあります。
main.tf
resource "azurerm_resource_group" "main" {
    name = var.resource_group_name
    location = var.resource_group_location
}

managementモジュールではリソースグループのみ記載しています。そのためresouce_groupモジュールのような名称を付けた方が良い気はしますが、今後複数のリソースをmanagementとして管理したいなぁと思ったためこう記載しています。どちらが有用かはわかりません。

variables.tf
variable "resource_group_name" {}
variable "resource_group_location" {
    default = "japaneast"
}

ルート側でresource_group_nameresource_group_locationを指定したいため上記のように記述しています。ただしresource_group_locationはdefaultに東日本を指定しているため、ルート側で指定がなければデフォルトの値でリソースを作成します。

実行

# 準備
az login
terraform init
terraform plan

Terraform used the selected providers to generate the following execution plan. 
Resource actions are indicated with thefollowing symbols:
  + create

Terraform will perform the following actions:

  # module.management.azurerm_resource_group.main will be created
  + resource "azurerm_resource_group" "main" {
      + id       = (known after apply)
      + location = "japaneast"
      + name     = "rg-dev-test"
    }

  # module.management2.azurerm_resource_group.main will be created
  + resource "azurerm_resource_group" "main" {
      + id       = (known after apply)
      + location = "japaneast"
      + name     = "rg-dev-test2"
    }

想定通り2つのRGが作成されます。moduleのazurerm_resource_group.mainが複数ありますがモジュールなので問題ないようです。削除するときにはターゲットにmodule.management2を指定することで片方のみ削除が可能でした。

terraform plan -destroy -target=module.management2

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated
with the following symbols:
  - destroy

Terraform will perform the following actions:

  # module.management2.azurerm_resource_group.main will be destroyed
  - resource "azurerm_resource_group" "main" {
      - id       = "xxx" -> null
      - location = "japaneast" -> null
      - name     = "rg-dev-test2" -> null
      - tags     = {} -> null
    }
terraform destroy -target=module.management2

もっとこうした方が良い等あればコメントください。

Dockerでnginxサーバを構築して自己証明書でHTTPS通信を実現する方法

やりたいこと

  • Dockerでnginxサーバを構築(Port 80, 443)
  • 証明書はオレオレ(自己証明書)を使用
  • nginxはリバースプロキシの用途

方法

手順についてまとめます。

コンテナ作成

以下のdockerコマンドを叩きます。ポートは「ホストのポート番号:コンテナのポート番号」で記述します。例として、8080:80に変更するとhttp://localhost:8080でnginxのサンプルページが表示されるようになります。-dを付け忘れるとコンテナがupにならないので注意。

% sudo docker run --name my-nginx -p 80:80 -p 443:443 -d nginx:latest
% sudo docker exec -it my-nginx bash

default.confの書き換え

OSはdebianを想定しています。

% apt update
% apt install vim
% cd /etc/nginx 
% vim conf.d/default.conf

confファイルを別に作る場合には/etc/nginx/nginx.confのimportを変更するのを忘れずに。

default.confに以下を記載します。

server {
    listen      80;
    listen 443 ssl;  # SSL
    ssl_certificate     /etc/nginx/ssl/server.crt;  # サーバ証明書
    ssl_certificate_key /etc/nginx/ssl/server.key;  # 秘密鍵
    server_name  localhost;

    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;

    # リバースプロキシ
    location / {
        proxy_pass https://www.google.com:443/;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

今回はリバースプロキシとしての役割を持たせるためにlocationを指定して別のURLにアクセスさせています。飛ばす先がないので適当にgoogle.comを記載。

ssl on;を記述すると80番もSSL扱いになるので注意してください。listenディレクティブの443でsslパラメータを指定しているため不要です。

OpenSSLで自己証明書を発行

nginxコンテナ内で直接証明書を発行します。

% mkdir ssl
% cd ssl
% openssl genrsa 4096 > server.key  # 秘密鍵
% openssl req -new -key server.key > server.csr  # 証明書著名要求
% openssl x509 -req -days 3650 -signkey server.key < server.csr > server.crt  # サーバ証明書

確認

通常のnginxであればsystemctl restart nginxで再起動しますが、今回はdockerコンテナなのでコンテナを再起動します。

% nginx -t  # 重要 : ここでエラーを吐く場合、コンテナが再起動できなくなる
% exit
% sudo docker restart [コンテナID]

動確

ブラウザでhttpやhttpsでアクセスできればOKです。

オプション

CentOSのコンテナにnginxを入れる

上記のようにdebianを使いたくない場合。

% sudo docker run --name my-centos7 -p 80:80 -p 443:443 -d centos:centos7
% sudo docker exec -it my-centos7 bash 

以下の内容で/etc/yun.repos.d/nginx.repoを追加します。

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1

nginxをyumでインストールします。

% yum update
% yum install nginx
% systemctl enable nginx
% systemctl start nginx

dockerコンテナでSystemctlを使う (非推奨)

上記ではsystemctlではなくdocker restartでnginxの再起動を行っていますが、dockerコンテナ内でsystemctlを使用する方法は一応あるようです。privilegedを有効かつ/sbin/initで起動実行することで特権モードでコンテナが立ち上がります。

% sudo docker run -d --privileged --name my-centos centos:centos7 /sbin/init
% sudo docker exec -it my-centos bash

ただしプロセスが暴走する可能性があったり、そもそもコンテナの使い方としてよろしくないため非推奨ですのでご注意を。