rubicure (2.0.0): All about Japanese battle heroine "Pretty Cure (Precure)". https://t.co/2ImrcNQ9QI
— rubygems_news (@RubygemsN) 2021年1月3日
https://github.com/sue445/rubicure/blob/master/CHANGELOG.md#v200
rubocopを最新にしようと思ったら最新のrubocopだとRuby 2.4以降必須になってたのでこの機会にRuby 2.2系と2.3系のサポートを切りました。
rubocopのバージョンを上げたのでソース上の差分が結構大きいですが機能面での変更点は無いです
今年新しく作ったものを作った順に紹介
今年の頭に作ったやつでたまにPRきてる。
最近GitHub本体のdependabotの方で go mod tidy 正式対応されたので go-mod-tidy-prはお役御免かなと思ってdeprecateにしました
下記エントリ参照
下記エントリ参照
下記エントリ参照
個人的には今年のイチオシ
今まで使ったことのないアーキテクチャで作りつつも、割と爆速で動くというのがウリ。
しかもGCPの費用が1ヶ月で1ドル切ってるのでお財布的にも嬉しい。（リリース直後にプチバズってアクセス増えたけどそれでも1ドルちょっと超えたくらい）
Cloud Functions実行時に毎回Secret Managerから機微情報を読み込んでるのでそこをGoのビルド時にいい感じに埋め込めばほぼ0円にできそうだが*1、今のままでも十分安いのでそこまでのモチベーションはないｗ
*1:FirestoreのQuota超えることもあるので完全に0円は無理
家だと座椅子なのですが座椅子で仕事しててクッションに不満があった時に同僚に勧められて購入。
長時間座ってても尻が痛くならないのが良い
ハッピーおしゃれタイム をやりたくて購入。*1
けどGoogle Earth VRで昔住んでた場所にVR帰省したり、バーチャルデスクトップでライブのBDや配信イベントの鑑賞してる方が多いかもしれない。
仮想大画面でライブ見るのいいですね。（目がむっちゃ疲れるけど）
「プリパラミュージックコレクションがあるならライブ版もあるのでは？」ということでググって見つけたので購入。
プリパラやプリ☆チャンのCGライブが好きなのでCGライブだけをずっと見れるのは神。
これをBGM(Back Ground Movie)でコードを書くとテンションMAX！
難点は推し*2のパートで手が完全に止まること。
Makuake で支援してたのが先月届いたので使ってます。
操作に慣れるまでに時間がかかったけど慣れたらかなり快適。
フル充電で9時間持つので仕事で使うには十分
これは #プリッカソン Advent Calendar 2020 - Adventar の2日目です。
10月の プリマップ 公開以降見た目はほとんど変わってないのですが裏側をちょいちょい改善してるのでメモ
公式の店舗リストの住所には「東京都新宿区西新宿１－１１－１ゲームホビー館」のように建物名が入ってることが多いのですが、この手の住所をそのままジオコーディング（住所から緯度経度を取得）すると高確率で意図しない緯度経度が返ってくるため「東京都新宿区西新宿１－１１－１」のように建物名を削ってやる必要があります。
この手の前処理はリリース前から実装自体はしてたものの、日本の住所表記はバリエーションが豊富なのでリリース以降も気づきベースでちょいちょい修正してました
プロダクトコードだけ見ると正規表現がアレなのでテストコード見た方が分かりやすいと思います。
2200件近い店舗情報をFirestoreに一度に保存する関係上GCPのPub/Subのtopic *1 を使ってCloud Functionsで大量に並列処理をしているのですが、topicに積むところが遅かったのでパフォーマンスチューニングしました。
デバッグログ仕込んで各処理の実行時間を計測したら改善できそうな処理が2箇所あったのでそれぞれ修正。
2200件もあるとPub/Subのtopicに積むだけで遅いのでgoroutineで並列化しました。ここだけで50秒から1～7秒くらいに改善。（実行時間があまり安定しない・・・）
削除された店舗一覧を調べるために「Firestoreに保存済の店舗一覧 - prismdbで取得した店舗一覧」みたいなことをやるためにGoのslice同士の引き算を行ってるのですが、そこの処理が遅かったのを改修。 ベンチマークレベルだと300倍速くなっていてCloud Functions上でも9秒から1秒前後に改善。
改修前はトータルで1分弱かかってた処理が4～8秒で終わるようになりました。
プリマップでは間接的*2に公式の店舗リストを使ってるのですが公式のデータが一部間違ってるせいでプリマップのデータも変なことになってたのでタカラトミーアーツさんに報告して直してもらいました。
プリ☆チャンとプリパラの公式サイトの遊べるお店の一覧を見てたらデータおかしいのがあったのでタカラトミーアーツさんのサポートに報告して修正してもらった
— sue445 (@sue445) 2020年11月25日
公式情報が直ったのでプリマップ( https://t.co/7KmVcO63oN )の情報も自動で直って便利！
報告した内容はスクショ参照（計16件） pic.twitter.com/pn9OpPMFbR
件数多かったけど報告したその日のうちに全部直してもらったので不満を持ってる人はどんどん報告すればいいと思います。
余談ですがタカラトミーアーツサポートへの連絡先は2つありました。
1つ目は返信不要なやつで2つ目は返信を受け取りたい時のものかと思われます。僕は修正報告を受けたかったので後者で報告しました。
プリマップでは店舗名をFirestoreのコレクションのKeyにしてるのでKeyが食い違うと同一店舗なのにプリパラとプリ☆チャンで1つずつ出てくる状態になって不便です。（こういうのが2200件中50件くらいありました）
明らかに情報が間違ってる場合には公式に直してもらえばいいんですが、今回のケースは完全にこっちの都合なのでプリマップ側で名寄せしてます。
ほとんどの場合「△△△△△（ゲームセンターや量販店の名前） ○○（支店名）店」と「△△△△△ ○○」で表記ゆれしてたので機械的に「店」を削るだけで済んだのですが*3、それでも名寄せできなかったものがあったのでそこだけ名寄せ用のマッピングを作りました *4
*1:sidekiqやresqueでいうところのqueueみたいなもの
*2:prismdbが店舗リストを取得して、さらにそれをプリマップが使っている形
*3:https://github.com/sue445/primap/blob/9366ac30761b83f5daf6578ae1a9f361e15940fb/function/config/aggregate_shops.go#L47-L54
*4:https://github.com/sue445/primap/blob/9366ac30761b83f5daf6578ae1a9f361e15940fb/function/config/aggregate_shops.go#L12-L31
この後20時からBNP公式YouTubeチャンネルで「アイカツ！」「アイカツフレンズ！」第16話を配信されるよ☆プレミア公開後はアーカイブされるのでそちらもチェックしてね♪
— アイカツプラネット！&アイカツオンパレード！アニメ公式 (@aikatsu_anime) 2020年12月1日
アイカツ！20:00〜https://t.co/6KcqOCSeR4
アイカツフレンズ！20:30〜https://t.co/rezQITX0eM#aikatsu #aikatsufriends
アイカツ16話見てるんだけど「チケット5万枚が2秒で完売」ってそれを売り切るシステムも相当やばいな・・・・（ISUCONより難易度高そう）
— sue445 (@sue445) 2020年12月1日
普通の人は5万枚のチケットを一瞬でさばいた神崎美月さん*1の知名度に着目しがちですが、僕は職業柄システムの方が気になりました。
会社でインフラを見ています。業務でのインフラ歴は4〜5年くらい。社内だとAWSとGCP両方分かるマンとして認知されています。
ネタなので過度なツッコミは禁止
チケット5万枚を2秒で完売させるためには雑な見積もりでサーバ数百台必要だと仮定します。
これだけの規模をオンプレミスで調達するのは大変なのでAWSやGCPなどのクラウドを使うことになると思います。
オートスケール（アクセス数やサーバの負荷に応じて自動でサーバを増減させる）という手もあるのですが、2秒で数百台までスケールさせるのはさすがに厳しいと思います。
参考：自社で運用してるシステムでGKEのオートスケールを導入しているのですがリクエスト数急増でサーバ5台増やすのに10分くらいかかっています。*2
チケット販売開始の日時はあらかじめ決まっているからその日時に合わせてあらかじめサーバをその台数まで増やして待機させておくのがベターでしょう。
これはAWSとGCPのどちらにも言えることですが、1つのAWSアカウントやGCPプロジェクトで作れるサーバの台数には上限があり数百台というのは初期状態では作れないのでサポートに問い合わせて上限緩和申請をすることになります。クラウド事業者や希望台数にもよってサポートでの対応完了日数が変わるのでなんとも言えないけど僕ならバッファ込で2〜3営業日くらいは見込みます。
チケットの在庫やチケットを販売したという情報を持つためにデータベースは必須です。（以降、データベース = RDBを前提に書きます。FirestoreやDynamoDBのようなKVSは知らん）
webサーバは横に並べることで負荷分散できるのですがデータベースは簡単に増やせないしオートスケールもできないのでここがボトルネックになりがちです。
AWSのRDS, AuroraやGCPのCloud SQLのようなフルマネージドなデータベースを使えばスケールアップ・スケールダウンはできるのですが、あくまでも手動だしスペック変更時に基本的に数分間のダウンタイムが発生するのでこれも予めつよつよスペックにしとく必要があります。
僕なら迷わず一番高いスペックを選びます。
今日日自前で決済システムを持つことはあまりなく、決済専用の外部サービスを使うことが多いです。
自分のアプリケーション（チケット販売サイト）が秒間2.5万リクエストに耐えられてもその先の決済システムが耐えられないと思います。（2秒間に5万リクエストとかなんて下手なDDoSより量が多いし普通にネットワークで詰まるのでは...）
神崎美月さんといえばアイカツ界の超メジャーアイドル。そのライブチケットとなれば当然負荷も予測されるので負荷試験も必要でしょう。
負荷試験をしないと実際にどれだけのサーバ台数が必要なのか分からないので僕ならやります。
未曾有のアクセスが来るのが分かってるのであれば当日立ち会っての監視も当然やるでしょう。僕なら絶対やります
チケット5万枚を2秒で完売させるチケットサービスの構成で頭がいっぱいで話の内容が全然頭に入ってこないw（職業病）
— sue445 (@sue445) 2020年12月1日
*1:https://dic.pixiv.net/a/%E7%A5%9E%E5%B4%8E%E7%BE%8E%E6%9C%88
*2:GKEだとpodをオートスケールする Horizontal Pod Autoscaler（通称HPA）とpodを収容してるnode（≒サーバ）をオートスケールするクラスタオートスケーラーの2種類のオートスケールがあるのですがここで言ってるのは後者の方です
gcov + lcovが無難
Goでテストを実行する時に -cover をつけるとお手軽にカバレッジが集計できるのですが、1パッケージずつしか出力されないので複数パッケージ構成のプロジェクトの時にプロジェクト全体のカバレッジが集計できずに困ります。*1
$ go test -count=1 -cover ./... ok gitlab.com/sue445/tanuki_reminder 0.066s coverage: 77.2% of statements ok gitlab.com/sue445/tanuki_reminder/enum 0.026s coverage: 100.0% of statements
にもあるように
-coverprofile coverage.out でgcov形式で出力が今の所最適解だと思います。
GitHubと違いGitLabはカバレッジ集計に標準対応しているというのがあります。
https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-coverage-parsing
CIのログに出力されたテストカバレッジっぽい文字列を正規表現で抽出するという割と力技な仕組なのですが、各言語のデファクトツールに関してはだいたい正規表現が用意されています。
GitLabのリポジトリ上で正規表現を設定しておくだけで最終的にリポジトリ上でカバレッジの推移のグラフが見れます。 *2
Coverallsに比べればだいぶ貧弱なのですがリポジトリに標準機能でついているという強みはあります。
もしこれで困る場合はCoverallsのような他ツールを使うか*3、lcovで生成したカバレッジレポートをGitLab Pagesにアップロードすればいいと思います。
tanuki_reminder だと当初 /coverage: \d+.\d+% of statements/ のような正規表現でカバレッジを収集してたのですが、1つのログに複数のカバレッジが出ていると後の方にあるものがそのジョブのカバレッジとして採用されて複数パッケージ構成になった時に変なことになりました。*4
いくつか手法を考えたのですが、lcovのgenhtmlコマンドでHTML形式のカバレッジレポートを作る時にプロジェクト全体のカバレッジがログに出力されることに着目してこいつを利用するようにしました
test: image: golang:1.15 stage: test variables: GCOV2LCOV_VERSION: v1.0.4 script: - mkdir -p coverage/ - go test -coverprofile coverage/coverage.out -covermode atomic ./... # Install and run gcov2lcov - wget https://github.com/jandelgado/gcov2lcov/releases/download/${GCOV2LCOV_VERSION}/gcov2lcov-linux-amd64.tar.gz -q -O - | tar xvzf - --strip 1 - chmod 755 gcov2lcov-linux-amd64 - export GOROOT=$(go env GOROOT) - ./gcov2lcov-linux-amd64 -infile "coverage/coverage.out" -outfile "coverage/coverage.lcov" # Install and run lcov - apt-get update - apt-get install -y lcov - genhtml coverage/coverage.lcov -o coverage/ # regular expression for genhtml coverage: '/lines.*\d+\.\d+%/' artifacts: paths: - coverage/
lcovを使ってるので後半部分はGo以外でも流用できそう
*1:Go 1.15時点では
*2:https://gitlab.com/sue445/tanuki_reminder/-/graphs/master/charts
*3: https://docs.coveralls.io/gitlab を見る感じGitLab CI対応はしてそうに見える
*4:https://gitlab.com/sue445/tanuki_reminder/-/jobs/836453936
Rails 6.1.0.rc1がリリースされましたが*1、activesupport本体に #compact_blank や #compact_blank! のメソッドが入った*2ので6.1.0.rc1以降と一緒に入れられないようにしてメンテ終了宣言しました。
