Gaming on Gentoo Linux

最近は、LinuxでPCゲームをやるのもかなり現実的になってきたので、その知見についてまとめた記事を書こうと思う。

自分がGentooユーザーなので、細かい部分はGentooを前提にした話になっているが、概要はLinux全般でモダンなPCゲームをやる時の参考程度にはなるだろう。

前提

GPUドライバのインストール

普通入ってると思うが、GPUに合わせてxf86-video-amdgpuかnvidia-driversをインストールしておく。

vulkan driverのインストール

mesa (OpenGL-like graphic library for Linux) でvulkanフラグを有効化しておく。

vulkanは、DirectXとかOpenGLと同じレイヤーのAPIで、3Dグラフィックのためのlow level API。概ねOpenGLをよりモダンな方向に刷新するための規格という認識で良いと思う。

(少し調べてみた所によると、ハードウェアを直接制御するレベルのlow level APIなので、めちゃくちゃ難しいらしい……。)

で、何故これが必要かというと、詳しくは後述するがDirectXを利用したプログラムを動かすための、互換実装がvulkanに依存しているからだ。

vulkanがちゃんと動作しているかを確認するために、vulkan-toolsをインストールしておくこともオススメする。

sudo emerge -a vulkan-tools

vulkan-toolsのvulkaninfoというツールでvulkan driverの情報が取得できれば、正しくvulkanが動作する準備が出来ているはずだ。

vulkaninfo
==========
VULKANINFO
==========

Vulkan Instance Version: 1.2.162


Instance Extensions: count = 17
===============================
    VK_EXT_acquire_xlib_display            : extension revision 1
    VK_EXT_debug_report                    : extension revision 9
    VK_EXT_debug_utils                     : extension revision 2
    VK_EXT_direct_mode_display             : extension revision 1
    VK_EXT_display_surface_counter         : extension revision 1
    VK_KHR_device_group_creation           : extension revision 1
    VK_KHR_display                         : extension revision 23
    VK_KHR_external_fence_capabilities     : extension revision 1
    VK_KHR_external_memory_capabilities    : extension revision 1
    VK_KHR_external_semaphore_capabilities : extension revision 1
    VK_KHR_get_display_properties2         : extension revision 1
    VK_KHR_get_physical_device_properties2 : extension revision 2
    VK_KHR_get_surface_capabilities2       : extension revision 1
    VK_KHR_surface                         : extension revision 25
    VK_KHR_wayland_surface                 : extension revision 6
    VK_KHR_xcb_surface                     : extension revision 6
    VK_KHR_xlib_surface                    : extension revision 6

Steamをインストールする

最近のPCゲームプラットフォームは、ほとんどSteamかEpic Gamesのどっちかだと思う。Epic Gamesについては自分が手を出していないので、後でLinuxでプレイするための方法を軽く紹介だけしておく。

GentooでSteamクライアントをインストールするにはPortage Overlayを使う必要がある。所謂サードパーティリポジトリみたいなもの。

GentooでOverlayを使う方法はいくつかあるが、laymanを使うのが簡単だと思う。入っていないならインストールしておこう。

laymanを利用して、steam-overlayリポジトリを追加する。

sudo layman -a steam-overlay

これでsteam関係のコンポーネントがインストール可能になる。

steamのクライアントをインストールするにはsteam-launcherパッケージをインストールする。

use flagはこんな感じ。全部ONで良い。

equery uses steam-launcher
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for games-util/steam-launcher-1.0.0.69:
 U I
 + + joystick     : Add support for joysticks in all packages
 + + steamruntime : Use the official steam runtime libraries
 + + udev         : Enable virtual/udev integration (device discovery, power and storage device support, etc)
sudo emerge -a steam-launcher

インストールが終わったらsteamコマンドで起動できる。/usr/share/applicationsにもエントリが追加されているはずなので、任意のデスクトップランチャーからも起動できるだろう。

Steam Play設定

Steamが起動できたら、Steam Playの設定を行う。Steamにはcompatibility toolという概念があり、それを利用してWindowsゲームをLinuxでも起動できる様にしてくれる。それを有効化しておく。この設定はゲームごとに上書きできるので、ゲームによっては設定を変える必要があるかもしれない。

f:id:joker1007:20210410204114p:plain

Protonについて

Linux上でWindowゲームを起動するためには基本的にProtonを利用することになる。Protonはwineをベースに作られたWindowsアプリケーションを起動するためのツールである。Protonではwineにゲーム周りで利用されるコンポーネントが諸々追加されている。

Protonは非常に優秀で、Steamで20本ぐらいゲームを買って試したが、全く起動すらしないというゲームはほとんど存在しなかった。一方で大体Window OSで直接起動するのに比べて、10%〜20%ぐらいの性能低下がある。

(追記: 優秀だというのは、wineに比べてという意味で、ゲームの種類によっては非常に苦手なジャンルがある。特にメモリ監視系のアンチチートツールが必須になる様なPvPのネットワーク対戦型ゲームは対応が困難だと思われる。自分が余りそのジャンルをやらないので、個人的には余り困っていない。)

WindowsのゲームではDirectXが必要なケースが大半だが、ProtonではDirectXの互換APIがデフォルトで組込まれている。昔はwined3dというコンポーネントDirectXの互換APIを提供していたが、最近のDirectX10以降はvulkanをベースにしたコンポーネントによって実装されている。そのためvulkan driverをインストールしておく必要があり、mesaのvulkanフラグを有効にしておく必要がある。

また、DirectXのバージョンによって微妙に実装しているコンポーネントが異なるのでややこしい。DirectX9, 10, 11はdxvkというツールによって実装されており、DirectX12はvkd3dというツールによって実装されている。

github.com

github.com

コントローラーの利用方法

自分が動作確認したのはPS4のDualShock4と、XBox One S Controllerなので、この二つを利用する方法を解説する。

PS4のコントローラーのドライバはLinuxカーネルに組込まれているので、それを有効にすれば認識する。具体的にはCONFIG_HID_SONYとCONFIG_SONY_FFを有効にすれば良い。

カーネルコンフィグの項目で言うと、 Device Drivers -> HID support -> HID bus support -> Special HID drivers にある。

XBoxの互換コントローラーの場合も組込みドライバがあり、JOYSTICK_XPADを有効にすれば良いのだが、これはかなり古いXBoxコントローラー限定で、XBox One S以降のコントローラーだと上手く動作しない。古いXBoxコントローラーや、サードパーティの互換コントローラーなら組込みのドライバで動作するはずなので、その場合はこちらを有効にすると良い。場所は、 Device Drivers -> Input device support -> Generic input layer -> Joysticks/Gamepads にある。

では、XBox One S Controllerならどうするかというと、xpadneoというオープンソースのドライバがあるのでこれをコンパイルしてインストールする必要がある。他にもいくつかドライバ実装があったのだが、これが一番ちゃんと動作した。

github.com

Gentooなら基本的にKernelは自前でコンパイルしているので、kernelモジュールをコンパイルする環境は揃っているはずなので、余り苦労は無いと思う。

リポジトリをクローンしてきて、hid-xpadneoディレクトリに移動し以下のコマンドを実行する。

make modules
sudo make modules_install

ちなみに、このドライバは何故かBluetooth専用なので、xpadneoを利用したい場合はBluetoothを利用できる様にしておく必要がある。

BTを利用する方法はこちらが参考になるだろう。

Bluetooth - Gentoo Wiki

BTが利用できる様になったら、ERTMと呼ばれる機能を無効化しておく必要がある。cat /sys/module/bluetooth/parameters/disable_ertmの出力がYになっていれば良い。無効になっていないなら、boot時のkernelパラメーターかmodprobeのconfigで設定を変更しておく。

例えばboot時のkernelパラメーターなら/etc/default/grubでこんな感じに設定する。

GRUB_CMDLINE_LINUX_DEFAULT=" bluetooth.disable_ertm=1"

xpadneoはかなりBluetoothドングルとの相性がシビアで、自分の環境だとBroadcomのチップの安定性が高く、CSR(Qualcomm傘下)製のチップはかなり不安定で微妙だった。

コントローラーや環境によって、ボタンのマッピングがおかしくなってる可能性があるので、レイアウト設定を確認しておく。

f:id:joker1007:20210410215506p:plain

f:id:joker1007:20210410215511p:plain

動作確認したゲーム一覧

大体、上記のことを実施すれば大抵のゲームは動作する。自分が実際にLinuxでプレイしたゲームは以下の通り。

  • Cyberpunk 2077
  • Dead Cells
  • DIRT Rally 2.0
  • Dyson Sphere Program
  • Ghostrunner
  • Hades
  • Hollow Knight
  • Metro Exodus
  • Noita
  • Nova Drift
  • Orwell
  • Oxygen Not Included
  • Satisfactory
  • ScourgeBringer
  • Skul: The Hero Slayer
  • Stellaris
  • ハードコア・メカ

(Linuxネイティブに対応しているものも含む)

何故かゲームによってはLinux Native対応を謳っていても、Windows互換モードじゃないと起動しないものが結構多くある。Dead CellsとかSkulとかはそんな感じだった。

また、Protonのバージョン次第ではコントローラーがちゃんと認識しない可能性がある。その場合、コントローラー設定をゲームごとに弄る必要があるかもしれない。

上記のゲームの中ではCyberpunk 2077が一番設定がシビアで2番目がMetro Exodusだった。設定が適切なら快適なのだが、噛み合わないとGPUごとハングアップしてPCが固まる場合がある。そうなると再起動するしかないので、AAAゲームを起動するのは結構大変。普通にWindowsデュアルブート可能にした方が楽と言えなくもない……。

Advance: mangohud, vkbasalt

mangohud: vulkan driverの情報や現在のfpsをoverlay表示できるツール

github.com

vkbasalt: vulkanのpost processingツール。レンダリングされた3Dグラフィックにシェードをかけたり、シャープフィルタかけたりできる。かなり画質が変わるのでゲームのよっては見た目がかなり綺麗になる。

github.com

上記の様なvulkan周りのツールを利用することで、ゲームの表示をカスタマイズできる。コンパイルしてインストールしたら、環境変数でオン・オフを制御できる。

ゲームごとの設定で、起動オプションを制御することができるので、そこに以下の様に設定する。

f:id:joker1007:20210410222346p:plain

ENABLE_VKBASALT=1 %command% 

vkbasaltはゲームによって多少相性があり、Cyberpunkみたいな設定がシビアなゲームで利用するとGPUごとクラッシュする可能性があるので、何でもかんでも使える訳ではないが、上手く動作するゲームならHDRモードみたいに色彩強化したり、かなりポリゴンの見た目を改善することができる。

Advance: SteamTinkerLauncher

Steam関連ツールは他にも結構色々あるみたいで、Vortexというmod管理ツールとか、ReplaySorceryというBackgroundでリプレイ動画をキャプチャしてくれるツールなどもある。

こういうのを逐一設定するのは面倒なので、SteamTinkerLauncher (stl) を利用して一括でオン・オフを管理することができる。

github.com

ここまでやる必要はあんまり無いのだが、関連ツールの情報が色々あるのでリポジトリを見ておくと便利なものが見つかるかもしれない。

stlはyadというgnomeのdialogウインドウを作るツールを使って色々設定できる様にしたshell scriptで、steamの起動の途中に挟み込んでゲームごとに色々な設定を読み込むランチャーとして動作する。

上記の起動オプションの項目を以下の様に設定する。

stl %command%

そしてゲームごとに色々設定するにはstl menuで起動した後、対象ゲームを選択し、GAME MENUから色々とオンオフしていく。異様に設定できる項目が多いので、正直自分も良く分かっていない。

Epic Gamesについて

自分はEpic Gamesを利用したことが無いので、実際どんな感じで動作させるのか良く分かっていないが、lutrisというツールを使うことで、Epic Gamesのゲームもプレイできるらしい。 Steamのprotonを利用することもできるはず。

Lutris - Open Gaming Platform

Linux:「Lutris」最強?のゲーム管理ツール | SlackNote

Linuxでのビデオ会議のためのオーディオ環境

Linuxに乗り換えようかなと思っている人向けにビデオ会議のためのオーディオ環境構築の一例を紹介する。

ハードウェア

Audio I/F: Focusrite Scarlett Solo 3rd Gen

focusrite.com

1万円ちょっとで買えるし、ダイレクトモニターも付いてるし、Linuxのusbaudioドライバで問題無く動作する。 音声入力に対して不満は無いが、ヘッドホンを刺して普通に音楽を鳴らすとめっちゃ硬い音がするので、入力にのみ利用している。

マイク: Shure SM58

www.shure.com

大分昔に買ったボーカルマイクを流用。コンデンサマイクではないが、1万円ぐらいで安い、単一指向性、丈夫、定番、という安定感のあるマイク。 これをテーブル置きのマイクスタンドに設置して利用している。 マイクヘッドを顔側に向けて、インターフェースのゲインを上げれば、30cmぐらい離れていても普通に拾う。

カメラ: Logitech C920 HD Pro Webcam

www.logicool.co.jp

これも1万円ぐらい。既に結構古いが大抵のノートPCのカメラよりは綺麗に映る。Linuxのuvcvideoドライバで問題無く動作する。オートフォーカスも問題なく動く。

ソフトウェア

ノイズ除去: noise-suppression-for-voice

github.com

ニューラルネットワークを利用したRNNoiseというノイズリダクションライブラリを利用したリアルタイムノイズ低減プラグインOSS (GPL-3.0)。

DAW等で良く利用されるVSTプラグインか、Linuxのpulseaudioで利用できるladspaとしてコンパイルできる。

しばらく利用しているがかなり優秀で、環境音はかなり低減できてキーボードをカチャカチャやる音はほぼ消せるし、マイクの側で呼吸しても呼吸音が聞こえなくなる。咳とかはタイプに依る感じ。乾いた咳は結構消えてくれる。

コンパイルの手間はあるが、使う価値はある。

pulseaudio設定: pagraphcontrol

github.com

pulseaudioの設定は基本テキストなので、グラフィカルにやれる様にしてくれるツール。ただ、自分はjack audioに乗り換えたので、こちらは余り利用していない。

pulseaudioをちゃんと設定すれば、特定のオーディオラインにだけエフェクトをかけたりできるし、zoomから流れてくる音声に対して自分のマシンでノイズ除去をかけたりできるのだが、そういうのを視覚的に楽にしてくれる。

jack audio設定: Carla

kx.studio

普通Jack Audioとか使わないと思うんだけど、もし利用したいならCarlaを使うと設定が楽になる。pagraphcontrolみたいにグラフィカルに線を繋げてエフェクトをかけられる。

Jack Audioを使う利点はpulseaudioより遥かにレイテンシを下げられたり、プラグインの幅が広がるところ。

おまけ: PulseEffects

github.com

もし、声や音に色々エフェクトかけて遊びたいなら、PulseEffectsを使うのが手軽で良い。エコーかけたりイコライザ通したり歪ませたり、基本のプラグインだけでも結構色々できる。

ビデオ会議ツールについて

zoomとかdiscordとかは普通に利用できる。ブラウザ系のミーティングツールも基本問題は無い。

ただwaylandを使っているとデスクトップキャプチャが結構面倒なことになる。pipewireとかを駆使すれば出来るらしいが、自分はwaylandを常用していないので余り試せていない。

まとめ

実際、音声周りはプロフェッショナルクオリティを求めないのであれば、Macよりよっぽど自由にやりやすいので、むしろMacより環境が良くなったと思う。

個人的には音声の聞き取り易さというのは結構会議中のストレスに影響するので、ちゃんとしたマイクとノイズ低減の工夫はした方が良いと思う訳で、何かしら参考になれば良いと思う。

2021年を戦うためのRyzen9 5900Xマッシーンを組んだ

年末、たまたま見つけたRyzen9 5900Xを勢いで買ってしまったので、そのまま流れで新しいPCを組むことにしました。 年始っぽくて良いかなとも思ったり。

構成は以下の通り。

Mother: ASUS ROG Strix X570-F Gaming (27k円)
CPU: Ryzen9 5900X (89k円)
Memory: ADATA DDR4-3200 64GB (non-ECC)  (24k円)
GPU: Sapphire AMD RADEON RX6900XT (150k円)
Cooler: NZXT Kraken X73 (24k円)
CASE: Fractal Designe Define 7 (23k円)
NVMe: CFDの1TB (16k円)
Power Supply: Owltech seasonic FOCUS PX-850 (21k)

合計で375000円ぐらい。全部増しMac Book Proよりちょっと高く付いたか、という感じです。 ノートPCと違ってディスプレイが別であることを考えると、割と奮発してしまった気がする……。

というかRADEON RX 6XXX系が全然売ってなくて、たまたま見つけたRX6900XTをこれまた勢いで買ってしまったので、予算が5万ぐらい増額されてしまった。 まあ、年始に今後数年使うものを組み上げるなら、範疇だろうとは思います。

中味はこんな感じ。

f:id:joker1007:20210108235739j:plain f:id:joker1007:20210110180657j:plain

結構レイアウトが工夫できるケースを買ってしまったので配線に悩んだり、先にAll-In-One水冷クーラー付けてしまってラジエーターの設置にえらい苦労したりしましたが、無事完成し起動しました。

top - 22:30:20 up  8:32,  3 users,  load average: 0.00, 0.16, 1.37
Tasks: 281 total,   1 running, 280 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu12 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu13 :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu14 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu15 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu16 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu17 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu18 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu19 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu20 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu21 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu22 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu23 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  64283.2 total,  61441.9 free,    585.0 used,   2256.3 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  63090.7 avail Mem

良いですね、12コア24スレッドと64GBのメモリ。

OSはいつもの様にGentoo Linuxを入れました。

% uname -a
Linux durandal 5.10.6-gentoo #1 SMP PREEMPT Mon Jan 11 02:51:36 JST 2021 x86_64 AMD Ryzen 9 5900X 12-Core Processor AuthenticAMD GNU/Linux

(良く見ると分かりますが、hostnameはdurandal。前のPCがfragarachだったのでジャンル的に近いものにした。代々続く厨二ネーミングです。)

Gentoo入れる時のトラブル

そもそも、zen3のCPUとRDNA2のRADEONが新し過ぎるので、Linuxカーネルはかなり新しいところを突っ込まないと色々と認識してくれませんでした。

5.4系でもCPU自体は認識して、FrameBufferのコンソールまでは立ち上げられます。 しかし、CPUの温度センサーが認識しなかったり、GPUカーネルモジュールがカードを認識してくれなかったりと、流石に運用できない感じですね。

なので、現行のgentoo-sourcesの中でほぼ最新まで上げました。まあ5.10系はLTSなのでその内Gentooでstable扱いの奴が出るでしょう。

その他のディストリだと、ArchかUbuntuFedoraの最新辺りを使えば、大体5.9以上になってるバージョンだと思うので多分大丈夫だと思う。

カーネルコンパイル時のconfigは、 AMDGPU - Gentoo Wikiに書かれている内容を良く読めば何とかなりました。(都度カーネルコンパイルしてる人はGentooユーザーぐらいだと思いますが……。)

忘れ易いのがfirmware類です。linux-fimwareパッケージを入れて、Firmware Loaderの設定にbinファイルの相対パスを入れてfirmwareを組み込んでkernel compileする必要があります。

その他、センサー類はCONFIG_K10TEMPとCONFIG_NVT6775を有効にしておけば大体問題無いと思います。

最近は、大体NVMeで共通のモジュールでストレージも動くので、後はそんなに困ることは無いと思います。

後は、水冷クーラーの流量調節ですが、 以下のツールを使うと良さそうです。 github.com

# liquidctl status
NZXT Kraken X (X53, X63 or X73) (experimental)
├── Liquid temperature    31.2  °C
├── Pump speed            1600  rpm
└── Pump duty               50  %

こんな感じです。

アイドル時はCPUは35度ぐらいで安定。全コアをフルでぶん回したら75度ぐらいで安定って感じです。 流石にフルパワー出すと、それなりに温度が上がる。

Terminal回りは大分使える様になったので、後はGUI回りを色々と整備していく所です。 この際だからwayland試してみようかなあとか思ってますが、上手くいくだろうか……。waylandだとawesome-wmが使えないんだよなあ……。

おまけ: Rubyベンチマーク

TwitterRubyコミッタのk0kubunさんから、Ryzen 9 5XXXでのoptcarrotベンチの結果が気になるという話を伺ったので、軽くベンチを取ってみました。 結果は以下の通り。

gist.github.com

1000万件オーバーのレコードのデータをカジュアルに扱うための心構え

自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。

大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。

そういったケースで参考にできるかもしれません。

弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。

追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オーバーの件数から数件取るとかそういう話ではなく数億件の中から1000万件を取得して数分以内に処理を終わらせるとかそういう処理を頻繁に(カジュアルに)実装しなければならない弊社の話でした。

1ノード, 1コアで処理してはいけない

  • 1件が200byteとしても1000万件を処理するなら2GB。これだけならメモリに乗り切らない程ではないが、オブジェクトにマッピングすると数GBを余裕で越えたりするし、1億件なら数十GBを越えるかもしれない。
  • 1件処理するのにかかる時間が1msecでも1000万件を処理すると1万秒 (3時間弱) かかる。
  • RubyはGILに引っかかるのでそもそも余り向いてない。可能ならマルチスレッドで処理を行い易いGoかJava辺りの利用を検討すること。(別にRustとかC++でも良いけど)
  • 上記以上の規模や負荷がかかる場合はノードごと分散することを検討する

通信回数を減らせ

  • 1度の通信が1msecで完了しても、1000万件を処理すると1万秒 (3時間弱) かかる。
  • 通信レイテンシやラウンドトリップタイムによってスループットの限界が決まる。通信回数が多いとワイヤースピードよりも遥かに低速で律速する。
  • redisキャッシュに接続してデータ取るのにもコストがかかる。

通信は常に失敗する可能性がある

  • 通信の信頼性はそんなに高くない。AWSの中でも度々不可解なネットワークの断絶が起きる。
  • 突然通信が終了すると、片側で終わったということすら検知できない場合があるため、状態遷移が中途半端な状態で処理が止まる可能性を考慮しなければならない

エラー対象を特定可能にしておく

  • エラーが起きた時に、どのデータに異常があったか判別できないと1000万オーバーのデータから大体の検討で探すことになり、非常に時間がかかる
  • 実装に不具合があった場合、特定パターンのデータが到達したら即座にシステムごと死ぬケースもある。
  • エラートラッキングサービスに必要なメタデータを付与してエラーを送る様にする
  • 一方で、ignoreして処理継続可能なエラーを都度トラッカーに送ると、一瞬で数十万のエラーが積み重なって課金額がえらいことになる危険があるので、注意すること。

リトライ可能ポイントを考慮しろ

  • リトライ機構は常に必要である
  • 1000万件処理している時の990万件目で処理が死んだ時、残りの10万件でリトライ可能にできるかを考慮する
  • 処理が複数ステップに跨る時は、ステップごとにコンポーネントを分けワークフローエンジンによってコントロールすること
    • 個別のステップを独立して実行可能にしてリトライ可能ポイントやテストデータ投入ポイントを挟む
  • 仕組みの単純化トレードオフになるケースもあるので、フルリトライが最善であるケースもある

羃等性の維持

  • リトライ時に状態の回復を要求すると自動リトライが困難になる
  • 処理の最初から流せば常に同じ状態になる様に設計することで、リトライに関わる処理が単純化できる
  • at least onceはexactly onceより圧倒的に処理負荷が軽い、羃等であるならat least onceで安全に処理できる
  • 羃等にすることが難しい処理に注意
    • カウントアップ等の今のデータからの差分を書き込む処理

分散処理ではロカリティ(データの所在)を意識する

  • 複数データのJOINが必要な場合、同一のキーであらかじめデータを同じ箇所に集めておいてから結合しないと、データの再配置が必要になる。再配置 = 大容量の通信処理であり高負荷。
  • 出力の全件Orderingは基本的に全てのデータを集約しないとソートできない

モニタリング必須

  • 関連するコンポーネントが増えるとボトルネックが分かり辛くなる。全ての箇所でモニタリング機構を整備すること。
  • コンポーネントに跨る様な処理の場合はdatadogに全体を俯瞰できる専用のdashboardを作る。
  • 最低限下記のリソースをモニタリングすること

    • CPU利用率とiowait
    • Disk I/O (iopsとスループット)
    • ストレージ消費
    • メモリ消費
    • ネットワークスループット
    • GC統計
    • 通信レイテンシ (中央値・最大値、90〜95パーセンタイル辺り)
  • 追加でモニタしておきたいもの

    • 無視できるエラーの回数、異常データの数や出現頻度
    • 処理遅延 (キューイングから処理されるまでの待ち時間)
    • DBへのqps
    • キャッシュヒット率 (キャッシュ機構がある場合)

余裕を持ったリソース確保 (staticかオートスケーリング かを問わない)

  • 唐突に大きな顧客からのアクセスが増えることがあるため、常に最低でも2倍ぐらいの負荷に耐えられる余地を残しておきたい
  • staticなノードの場合は、上記の様にモニタリングをしっかり整備し、早い段階でノード追加、スケールアップを行える様にアラートを整備する
  • それ以外のノードはオートスケーリングもしくは処理のキューイングに応じて自動的に必要なリソースを確保する機構が必須である
    • FargateやLambdaも活用できるし、リソース確保が簡単になる。それらの制約に対応出来る場合は検討の余地がある。
    • オートスケーリングの基本は増やす時は大胆に増やし、減らす時は少しづつ減らす

工程毎のログを吐け

  • バルク処理は長時間動作する上、複数ステップを伴うことがあるので、適宜ログを吐かないと、どこまで進んでいるか分からない。
    • 特定処理でスタックしてエラーにもならなかった場合に、進捗が確認できなくなる状態を避けたい
  • 一方で一件単位で詳細なログを吐くとログのデータサイズやログ出力の負荷が馬鹿にならないので、レコード個別のログについては必要性を考慮すること

汎用的なETL基盤を構築すること

  • importやexport等を個別の機能ごとに作るべきではない
  • 個別に作るとスケーラビリティの問題に個別で対処しなければならなくなる
  • 現状だとembulkをラップして実行できる基盤を準備し、必要があれば適宜プラグインを書くと概ね対応できる。

既存のコードを信用するな

  • 誰が書いたコードであっても1年以上前のコードがベースになっている箇所を信用してはならない
    • 実装を理解し現時点でも問題無いかどうかを確認すること
  • 1年あれば提供規模や顧客規模も変わるし、会社として注力している箇所も変わる。

    手癖で書くな

  • 量が変われば解決方法が変わる
  • 1年前と同じ方法では機能提供できないケースが多い
  • 特にWebシステム開発の手癖をバルク処理に持ち込んでは駄目。

クラウドサービスを使え

  • クラウドサービスの機能を理解し、不要な開発工程を減らすこと
  • ちょっとでも関係しそうなサービスを見かけたらとりあえずドキュメントを読む癖を付けておかないと、いざという時に思い付かなくなる。
  • 以下のサービスはデータ処理基盤において特に重要で、日常的に検討対象に入るので定期的に復習し新機能をキャッチアップすること
    • S3
    • SQS
    • SNS
    • Elasticsearch
    • ElastiCache
    • ECS/Fargate
    • StepFunctions
    • CloudWatchEvents

追記: 社内用の資料から対象を絞り込んだ時に消えてたもの

  • EMR
  • Athena

Kaigi on Rails 2020に登壇して、Kafkaを使ったサービス分割の話をしてきました。

2020/10/3 に開催されたKaigi on Rails 2020に登壇してきました。

オンラインのイベントやカンファレンスに登壇したことはあるんですが、今迄割とカンファレンスの現場感みたいなのが薄いなと感じる中で、Kaigi on Railsはかなり以前の祭り感みたいなのを感じることが出来て、とても良いカンファレンスだったと思います。

特にSpatial Chatでカンファレンス会場の廊下っぽい空気を完璧とは言えないまでも再現出来てたのはとても良い試みだと思いました。

さて、私はというとキーノートを除いた通常発表のトリとして発表させていただきました。

(午前だったら寝坊してたのでやばかった……、運営チームの気遣いに感謝しておりますw)

内容は以下の通りです。

speakerdeck.com

背景とか反省とか

RailsというWebアプリケーション開発のフレームワークを中心にしたカンファレンスということで、割と業務ドメイン特有の要素が前提になっていても良いかなあと思い、無理に一般的な話として頑張らないことにしました。

最近、増え続けるデータ量と複雑化するデータパイプラインの活用に頭を悩ませ続けているので、そういった高負荷な非同期処理が連鎖する環境でKafkaを活用してサービスをバラしつつ高トラフィックかつ複雑な処理を実装する、ということをやってまして、Railsでやってたころとどの辺りが違うのか、という話を中心に資料を作りました。

発表後にTwitterで何人かに「何故こんなことをRailsでやるのか分からん」みたいな感想をもらいましたが、自分も「ほんまそれ」と思いますねw

私がこの会社に正式に入ったのは4年ぐらい前で、当時は扱うデータは数百万件ぐらいだったんですよ。トラフィックも総データ量も当時から100倍以上は増えていて、しかもビジネス上重要だった機能を廃止して注力する方向を変えたり等もあって、根本的に構造が噛み合ってない箇所がいくつか残ったりしている状況でした。

なので、最初のころはRailsでも何とかなったっちゃなった訳です。

で、増え続けるトラフィックに対応しつつ機能開発をやり、その中で段階的にRailsと噛み合わない処理を色々と引き剥がしてきたので、こういう感じになっているという背景があります。

そういった機能開発要求の中で特にハードだったのが、データパイプラインの準リアルタイム化で、バッチベースの処理から大きくアーキテクチャを転換する必要に迫られました。

そこでアーキテクチャの中心にKafkaを置いて、業務のコアとなるデータパイプラインとWebアプリケーション側の非同期処理の複雑な非同期処理を上手く連携できる仕組みに寄せていこうと判断しました。

今回の発表は、そういった開発の流れの中で現在進行形で戦っている最中の話でした。

今も試行錯誤している最中の話だし、私自身が全ての範囲を見て実装できている訳ではないので、きっちりまとめ切って確信を持って話しが出来なかったのが多少心残りではあります。

特に、一般化してコードに落としたり知見をgemにまとめたりといったことが全然出来ていないので、そこは大分残念でした。

そして、いざ資料を書いてしまったら補足説明とかで色々と書き過ぎた結果、20分に全然収まらなくなってしまって、すげー発表時間をオーバーしてしまいました……。申し訳ありません。(この辺りも順番が最後の方でまだマシだった)

やっぱ、登壇経験がそこそこあっても、ちゃんと時間測って喋るリハーサルやらないと駄目だなーと反省しております。

結構資料が難産だったので、サボってしまったのが良くなかったですね。

という訳で、今回の発表は自己評価としては微妙な感じになってしまいましたが、何かしら伝わるものがあったなら幸いです。

来年もKaigi on Railsをやるぞ、という感じらしいので、またコンテンツ提供出来る様に頑張りたいと思います。次回もよろしくお願いします。

(来年はオフラインで集まれるんだろうか……)

パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について

最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。

数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述)

何故こんなことが起きるのか

そもそも、フロント側に何故IPアドレスを送ってんだ、という話ですが、いくつかのブログ記事に書かれている様に、ActiveRecordがUserレコードに詰め込まれている色々な情報をSELECT * FROM usersで引っ張ってきてしまって、json変換する時に参照してしまってフロントに漏れたんでは、というのは想像できる話ですね。

Railsというフレームワークデファクトとして使われている認証機構構築ライブラリのdeviseは、とにかく色々な機能が組込まれており設定と簡単なDSLでパスワード認証、メールアドレス認証、パスワードリセット、ログイントラック等ができる様になります。

しかし、これを何も考えずにざっと作ったUserモデルでポコポコ有効化していくと、上記の様な問題に繋がる可能性はあります。

ただ私としては、こういう事情があったからといって別にDeviseを使うべきではない、とまでは思いません。というか改めて確認してみましたが、Devise自体はこの問題についてはちゃんと対処済みです。具体的にはdeviseのモジュールをincludeしたら時点でserializable_hashが上書きされ、to_jsonとas_jsonからdevise関連のカラムを除外する様になってます。(ソース)

むしろ、Deviseの構成元にして半端にパクったものを自作する方が危ない例の一つと言えますね。まあ、どっちにしてもto_jsonをそのまま渡すのは止めた方が良いやり方であることは間違いないです。Deviseの防御機構もこれで安心か、と言われると色々と説明が無さ過ぎて何とも言えないところです。READMEに書いてるRailsの知識が全然無いなら使わない方が良いよ、というのはこういう所に現れているのかなという感じです。

結局のところ、これはRailsがどういうフレームワークとして成り立ってきたかということと現代的なWebアプリケーションの実装におけるモデル構造とが乖離してきており、現代的なモデル構成が取れていないという点に問題の根幹があるからで、別にDeviseを使おうが使わなかろうが、同じ様なモデル構成を取って雑にフロントに渡せば同じ事故が起き易くなります。

私見ですが、Deviseが採用している基本形であるUserモデルに認証に付随する様々な機能をぶち込むというのは、現代において余り良い方法ではないし、それを参考にして半端にパクった認証機構を作ると尚のこと危険である、と思っています。(とにかくdeviseは初心者向けのサンプルが悪い)

Railsというフレームワークはv1.0から数えても既に15年近い歴史があり、充分な老舗フレームワークです。そして、Railsは現代においても充分に便利で強力なフレームワークですが、JSの扱いにおいては現代の潮流とは割と異なった流れに乗っています。

SPAというものを余り重視しておらず、現代においても基本的にはRailsはHTMLを出力するフレームワークという立ち位置が基本だと思っています。そういうフレームワークなので先進的なJSコミュニティからの評判は余り良くないようです。

HTMLを出力する場合、HTMLテンプレートのそれぞれの箇所に「この情報を出すぞ」とバックエンドも触っている人が明確に決めて記述するので、あるモデルに必要ない情報が混じっててもサーバーの向こう側に届くことはありません。

一方でSPAの様にフロントサイドでレンダリングしてDOMを弄くりまわす様な構成のアプリケーションの場合、フロントエンドとバックエンドで開発の専門性が異なるケースがしばしばあるため、バックエンドからまとめて情報を渡して後はフロントエンドでよしなに扱ってくれ、という方向に意識が向く場合があります。

そうすると、昔ながらのRailsの様に何でもかんでもUserに突っ込んでActiveRecordでよしなにやる、みたいな考え方でモデルを構築していくと、事故る訳です。

Deviseも10年近い歴史があって、そういう所からスタートしているので、昔からの情報やREADMEにある情報だけでは、現代的なWebアプリケーションと合致しない箇所がしばしば出てきていると思います。

そもそもSPAは難しいものです。サーバーサイドという自分達の環境に情報を閉じ込めておけないので、サーバーサイドでデータを取り扱うのに比べて、何を持つべきで何を持つべきでないのかを遥かにセンシティブに考える必要があります。

防衛策

じゃあ、どうやってこういったことを防ぐと良いのか。サーバーサイド側で責任を持つなら、必ず明示的にattributeを列挙するシリアライザかjbuilderの様なjson builderを通して、暗黙的なデータ渡しを行わない様にすることが基本になります。render json: @hogeは止めましょう。まあ、固定でエラーメッセージを返すエラーハンドラとかなら問題無いと思いますが、余計なお節介としてエラーになったオブジェクトの情報も付けとくか、とか思ってしまうと死ぬので気は使いましょう。

フロントサイドでも明示的に必要な情報だけをくれ、とサーバーサイドに要求することは出来ます。それにはGraphQLが使えます。GraphQLではフロント側から明示的に必要な属性値を列挙してリクエストを行うため余計な情報を取得してしまう可能性を下げることができます。フロントとバックエンドで開発体制を分業しつつ、安全性と柔軟性のバランスを取った仕組みと言えます。

そして、そもそも余計な情報をUserに持たせない様にモデルを作っておくという方法も取れます。人間書いてればうっかりしたりサボったりするもので、何事も見過ごす可能性があるもので、最初に防御的に作っておけばそういった時に事故を防げる可能性が上がります。Railsは良くも悪くもRDBと密結合したフレームワークなので、まずテーブル構成からしっかりやっておけば、それなりに安全性が上がります。

Deviseでこういうデータベース構造を取ろうとすると多少の工夫が必要になるのが残念なところですが、そもそもテンプレのまま作れるユーザー認証基盤というのはお試しアプリぐらいなものなので、割り切って多少コントローラーとviewを弄るぐらい普通だと考えた方が良いんじゃないかと思います。ログインを要求するモデルはUserに限らずAdministratorとかOperatorとか色々あったりするので、コントローラーとviewをdeviseから分離して弄るのは、実務の場合ほぼ必須なので。

じゃあ、どういう風に弄るのかという例を紹介していこうと思います。

ユーザー認証関連のテーブル設計

昔はただユーザーIDとパスワードで認証できればそれで良かったのですが、昨今のWebアプリケーションでは遥かに多くのことが必須になっています。現代のユーザー認証において求められる機能や前提は以下の様なものになります。

  • 古典的なパスワード認証
  • Twitter/Google等の各種サービスアカウントを利用した認証
  • APIのためのトークン認証
  • メールアドレスの存在確認
  • パスワードリセット
  • 2FA
  • アカウントロック

これらを都度自作するのは、非常に大変です。認証だけなら割と何とかなりますが、メールアドレスの存在確認やパスワードリセット等は、ユーザー側からの要求を受け付けるビューやエントリポイントがあって、更にそれらの有効期限管理等が絡んでくるため、サーバサイドだけで話が完結しないし状態遷移が長時間に渡って継続します。Deviseが使われる理由は主にこの辺りにあります。

という訳で、Deviseを使って工数を削減したいが出来るだけ安全に使いたい場合にどうすれば良いのか、というと話は単純で機能毎にテーブルを分けた方が良いだろう、と私は考えています。

認証部分のテーブル分割の例

Userというその他のリソースと関連するモデルに持たせるのは、そのアカウントとしてログインしているならほぼ常に必要とするデータだけを持たせる様にしましょう。ID、ログインネーム、メールアドレスのみぐらいが良いですね。 そして、認証機構毎にテーブルを分けます。例えば以下の様なモデルを作ります。

  • User::DatabaseAuthentication
  • User::TwitterAuthentication
  • User::GoogleAuthentication
  • User::ApiTokenAuthentication

(User名前空間に作ってますが、定数の扱いで事故る可能性もあるのでUser prefixとして作っても良い。管理のしやすい方で)

こうすることで、特定の認証を必要としないユーザーはレコード自体を作らないで済みますし、必要なユーザーのカラムはほぼ全てNOT NULLにできます。

もし、後から2FAに対応してくれ、という要求があったとしても、新しくテーブルを作れば対応できます。既存のモデルに与える影響は小さくできるでしょう。

登録前確認やリセットやロックについての分割の例

登録前確認やアカウントロックの場合は以下の様なモデルを作ることになるでしょう。

  • User::Registration
  • User::AccountLocking
  • User::PasswordResetRequest

この様にテーブルを分けるのは、RESTfulなエントリポイントを作る上でも親和性があり、デフォルトでエントリポイント毎に必要な情報のみ受け渡す様に制限されます。 また、RDBのレコードを頻繁にアップデートしたり、NULLABLEなカラムが多数存在するのは状態管理や異常データの検知を複雑化させるので、出来る限り避けたいところですが、こういったテーブル構成を取ることでレコードがあるか無いかと、一つか二つ程度のカラムの整合性を確認するだけで正常かどうかを判断できる様になります。 レコードのvalidationを行う時には、境界を明確に分けて組み合わせが爆発しない様にコントロールすることが重要になります。

例えば、登録プロセスの途中でメールアドレスの存在確認を行い確認出来た場合にのみ、アカウントを利用可能にしたい場合、ユーザーの登録途中、という状態をUserモデルに持たせない様にし、ユーザー登録という行為自体を事実として記録します。こうすることで、中途半端な状態のUserレコードや関連リソースを作らずに済みます。

この様に機能毎に単一目的のモデルにしておくと、これらのレコードは用事が終わった時点で完全に削除することができます。そもそも一時的な情報でしかないので、最悪何らかの事故や実装上の問題によってテーブルごと作り直しても致命的な問題になり辛くなります。

もし機能の必要性が無くなれば、モデルと関連しているコントローラーごと消せば済むし、後から必要になってもUser本体へのmigrationが不要です。

Userというとにかく肥大化しがちで絶対に失ってはいけないレコードに、一時的な要求でしか使わない情報を持たせるのはほとんどの場合で悪手でしょう。

サンプルコード

一応、User, User::DatabaseAuthentication, User::Registrationとモデルを分割しUserモデルを極限までコンパクトにした動くサンプルを用意してみました。3時間ぐらいで作ったので登録とログイン回り以外は張りぼてだし、もっと調整する所色々あると思いますが、まあどうやって弄るのかの参考ぐらいにはなると思います。

github.com

各テーブルのカラムはdeviseが必要とするものと名前だけという最小構成です。

class DeviseCreateUsers < ActiveRecord::Migration[6.0]
  def change
    create_table :users do |t|
      t.string :nickname, null: false

      t.timestamps null: false
    end

    add_index :users, :nickname, unique: true
  end
end
class DeviseCreateUserDatabaseAuthentications < ActiveRecord::Migration[6.0]
  def change
    create_table :user_database_authentications do |t|
      t.references :user, foreign_key: true, dependent: :destroy,  index: {unique: true}
      ## Database authenticatable
      t.string :email,              null: false
      t.string :encrypted_password, null: false

      t.timestamps null: false
    end

    add_index :user_database_authentications, :email, unique: true
  end
end
class DeviseCreateUserRegistrations < ActiveRecord::Migration[6.0]
  def change
    create_table :user_registrations do |t|
      ## Confirmable
      t.string   :confirmation_token,  null: false
      t.datetime :confirmed_at
      t.datetime :confirmation_sent_at
      t.string   :unconfirmed_email
      t.string   :email

      t.timestamps null: false
    end

    add_index :user_registrations, :confirmation_token, unique: true
    add_index :user_registrations, :unconfirmed_email, unique: true
  end
end

モデルはこんな感じ。

class User < ApplicationRecord
  devise :authenticatable

  has_one :database_authentication
end
class User::DatabaseAuthentication < ApplicationRecord
  belongs_to :user
  devise :database_authenticatable, :validatable
end
class User::Registration < ApplicationRecord
  devise :confirmable
end

何故Userを:authenticatableにしているかというと、もし複数の認証基盤に対応することになった場合、database_authenticationのsign_inが行われていなくてもuserという大本の方でsession管理する方向に修正できる様にしてあります。

で、次にコントローラーを多少カスタマイズします。

デフォルトの挙動ではUserが先に作られていることを前提にしているので、registrations#createのsuperを呼ぶ前にregistrationが無ければ作成する様にしておきます。後は、renderするテンプレートやredirect先を適宜調整します。

この時点でaction_mailerからメールが飛び、トークン付きのURLが送信されます。(development環境ならデフォルトで本文がコンソールに表示されます)

デフォルトのconfirmations_controllerは確認が取れたら、ログイン画面にredirectしますが、controllerを少しだけ上書きし普通にshowテンプレートをレンダリングする様にします。

コードは以下の様になる。

class User::RegistrationsController < Devise::ConfirmationsController
  # GET /resource/confirmation/new
  # def new
  #   super
  # end

  # POST /resource/confirmation
  def create
    user_registration = User::Registration.find_or_initialize_by(unconfirmed_email: params[:registration][:email])
    if user_registration.save
      super do
        flash[:notice] = "Sending an email confirmation instruction"
        return render :create
      end
    else
      respond_with(user_registration)
    end
  end

  # GET /resource/confirmation?confirmation_token=abcdef
  def show
    super do
      @user = User.new
      @user_database_authentication = User::DatabaseAuthentication.new
      return render :show
    end
  end
end

そして、showのテンプレートに本登録に必要なパスワード登録等のformを記述します。 (面倒なので省略)

このフォーム画面は、有効期限内のメールアドレス認証トークンを持っている場合のみアクセス可能です。

後はフォームの受け取り先で、transactionを使ってUserとUser::DatabaseAuthenticationを登録します。UserはただのIDの箱みたいなものなので何も気にせず作ることができます。User::DatabaseAuthenticationもモデルがsaveされる時にdeviseが良しなにやるので、普通にモデルをnewしてsaveすれば問題ありません。(自分でソースコードは読んでおきましょう)

コードで書くとこんな感じ。

class User::RegistrationsController < Devise::ConfirmationsController
  def finish
    self.resource = resource_class.confirm_by_token(params[:confirmation_token])
    ActiveRecord::Base.transaction do
      @user = User.new(nickname: params[:nickname])
      @user_database_authentication = User::DatabaseAuthentication.new(user: @user, email: params[:email], password: params[:password], password_confirmation: params[:password_confirmation])
      @user.save!
      @user_database_authentication.save!
      self.resource.destroy!
    end

    sign_in(:user, @user)
    sign_in(:database_authentication, @user_database_authentication)

    redirect_to posts_path
  rescue
    render :show
  end
end

丁寧にやるなら、showで表示するformのためにFormクラスを作っても良いでしょう。

後、Deviseはroutingの設定が無いとDevise.mappingsに登録されず組込みのコントローラーを使えなくなってしまうので、routes.rbも設定しておかないと駄目です。

Rails.application.routes.draw do
  devise_for :user, skip: :all
  devise_for :database_authentications, class_name: "User::DatabaseAuthentication", controllers: {
    sessions: 'user/database_authentication/sessions'
  }
  devise_for :registrations, class_name: "User::Registration", controllers: {
    confirmations: 'user/registrations'
  }
  devise_scope :registration do
    post "/registration/finish", to: "user/registrations#finish",  as: "finish_user_registration"
  end
  devise_for :users
  resources :posts
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
end

とまあ、こんな感じで調整していけば、そんなに魔術的じゃない感じでdeviseの機能を利用できます。モデルのモジュールとcontrollerのソースコードは追えないと駄目ですが、利用に際した前提条件と言えます。(wardenは流石に深く突っ込まなくても大丈夫だと思うけど)

コントローラー名とかURLとかもうちょっとどうにかしようがありますが、とりあえずこの様にして不要な情報をUserから引っ剥がしていくことは出来ます。

認証機構って実はあんまり作る機会が無いんですよね。最初から必要なのでプロジェクトの立ち上げ期に参画してないと余り触らない。しかも後からモデル構造弄るのがめちゃくちゃ大変になるので、微妙な作りになっててもほとんど修正されないことが多いし。

という訳で、この機会にユーザー認証のモデル構造がどうなってると良いのか考え直して、素振りしてみても良いんじゃないでしょうか。 (正直、deviseどころか久しぶりにRails触ったんで、routingの設定とかマジ分からんってなってた……)

パーフェクトRails 増補改訂版の自身の担当分について

長らく改訂版をお待たせしていたパーフェクトRailsがついに新しくなります。 私は、やはり人間は締切が近くならないと働かない、という極めて重要な事実を改めて学ぶことができたのが良かったと思っています。

そろそろ献本させていただいた本は届き始めている様で、ブログやTwitter等で紹介していただけて嬉しい限りです。 全体の解説や紹介はそちらに任せるとして、私は今回担当していた箇所が大きく変わったので、それについての感想や裏話を書こうかと思います。

前回担当していた箇所

前回は、基本的に終盤のRailsの基本機能を越えたアプリケーションを作る時に助けになる章を担当していました。

元々は、そういう仕事としてRailsアプリケーションを書く上で気にしておきたいこと、というのが書かれた本が余り無く、何とかそういう本を作りたいという思いがあったので、あの辺りの章を担当させてもらいました。

正解の無い部分にオピニオンを打ち込むという意志の元に書いたので、今となっては自分から見ても多少考え方が変わっていたりする箇所もあります。

Railsを余り触っていない2年間

一方で、私自身はというと、ここ2年ぐらい余りRailsを触っていませんでした。 Railsコンポーネントを使うことはあってもWebシステムとして使っておらず、ActiveRecordRDBをどうやって引き剥がすか、みたいなことばかり考えています。 利用している永続化層もCassandraとかKafkaとか分散ミドルウェアが中心になっており、Rubyから触るにしてもRailsで全くカバーされない範囲になっています。

直近数ヶ月で一番書いてる言語は間違いなくJavaです。

今回担当した箇所

という訳で、現代的なRailsの実践編を執筆しなおして纏めるには、どうにも説得力あるものを書ける自信がありませんでした。 このままでは本が出せないという感じなので、自分から誰かに依頼できないかと考えていました。 そこで今回お願いさせていただいたのが、やさいちさん(twitter: @_yasaichi)です。

RailsDM 2019という大きめのイベントがあったのですが、そこでRuby on Railsの正体と向き合い方という内容で登壇されていました。 私の過去の発表や私も参考にさせていただいたスライドも参照した上で、現代的なWebアプリケーションの考え方に沿っている内容で上手く纏められた素晴らしいトークでした。 私がそれを聞いていたのもあって、今回の改訂版にあたって私が過去に書いていた箇所を引き継いでもらえないかと依頼したら、やりますと言っていただけました。(本当にありがとうございます。めちゃくちゃ助かりました。)

私が以前に担当していた箇所はしっかり引き継いでいただけたと思いますし、改訂版でもしっかり紙面が確保されています、ご期待ください!

じゃあ私は何を書いたかというと、コンテナでRailsを動かすという章です。 昨今、先進的なRailsの現場では大なり小なりコンテナが使われていると認識しています。一方で本番環境では使われていないという話もそれなりに耳にします。 Railsをコンテナ環境で動作させる知見が書籍の中に纏まっていれば、それなりに価値のある情報になるだろうと思いました。

弊社では2016年辺りからコンテナを本格的に導入しており、私自身そこそこ知見を持っているということと、複数のミドルウェアを利用したアプリケーションのデプロイやテストのために、コンテナのセットアップは頻繁に業務として実施しているので、この章を担当するのが良いだろうということになりました。

内容は概ね以下の通りとなっています。

  • Infrastracture as Codeの歴史とDockerの意義
  • 効率的なコンテナイメージの作り方 (レイヤーキャッシュとかマウントキャッシュとか)
  • 開発環境での利用方法 (docker-composeとか)
  • 本番環境に向けて注意しておく点
  • オーケストレーションサービスの紹介

実際書いてて思いましたが、マジのproductionレベルで実際にコンテナを活用するなら、オーケストレーションサービスの活用は必須なんですが、それについて説明をしだすと少なくともECSかKubeのどちらかについてまともに解説を書かなければならず、1章どころでは済まなくなります。 流石にRailsの本でそこまでボリューム取るのも難しいし、私自身の余力もそんなに無かったのもあって、本番環境でコンテナ運用が出来る様になるまでの前段階という形に留めることになりました。 (弊社だとECSを採用していてkubeの知見がそんなに無いとかもある)

一応、本書で纏めた内容はそのために必ず考慮しておかなければならない要素になっていて、ここをカバーしていれば自分達が選択したオーケストレーションについて学習するだけで一気に本番環境での活用が近くなる内容に出来たとは思っています。 特に設定値と秘匿情報については読み込む方法のイメージを事前に考慮しておかないと、後々で移行しようとすると結構面倒なことになります。

私の担当箇所はこんな感じになってますが、その他の内容も一線で活躍しているメンバーが最新のRailsを対象に知見をまとめた物になっています。 紙の本としては相当なぶ厚さになっているらしいですが、その分情報量はパーフェクトと言える内容になっているでしょう。 電子版も割とすぐに出るらしいので、重そう……って感じの人は是非電子版で購入を検討していただけると幸いです。