00:04
mutable stream 第4回目かな。始まりました。
いい加減回数をカウントして持ってこいと言われそうな。
ちょっとメモしておきましょう。
今日はファシリ私、chanyouこと中村がやります。よろしくお願いします。
よろしくお願いします。
一応、名前と簡単な自己紹介あれば、 じゃあ、ゴダンさんお願いします。
普段開発やったり動画作ったりしてます、ゴダンです。よろしくお願いします。
お願いします。最後、てつじさんお願いします。
小型てつじと申します。Xてつじとも呼ばれています。
サーバー運用だったりとか、いろいろやってます。よろしくお願いします。
お願いします。だいぶラジオも慣れてきたというか。
そうですね。ちゃんとリマインドセットも、 時間通り凍れるようになったあたりが得意。
週間っぽくなってきましたね。
今日は、一人ひとネタぐらい1テーマずつ持ってきて、 話すスタイルもいいかなと思って、
私が提案して、よし、やってみようという話になったので。
早速、ゴダンさんに振ってもいいですか?
もちろん、問題ないですけど。
ネタっていうと、ちょうど今、 収録が7月28ということで、
先週、技術的なイベント何があったかというと、 ISCON12でございます。
知っている方多いと思いますけど、
LINE株式会社さんが運営されている、 いい感じにスピードアップする。
サービスをいい感じにスピードアップさせる コンセプトの名前でございます。
一応、ちょっと参加してきまして、
これで予選通過しましたって言うと、 ラジオとして非常にきれいなんですけど、
残念ながらちゃんと残廃してきたというのが、 ネタといえばネタですね。
ISCONは僕は参加したことないんですけど、 具体的にどういうことをやるんですか?
僕が知っているのはエンジンXのパフォーマンスを 調整してみたいなことをやっているみたいなのは、
過去に見たり聞いたりはあるんですけど。
せっかくなので、今回ISCON12予選ということで、 問題が出たんですけど、
問題のテーマがMultitenant SaaSですと。
内容としては、これぜひ公式がかっこいい動画を 出してくれているので、見ていただきたいんですけど、
Multitenant SaaSでISCONのランキングボードを 見るためのサービスをしますと。
03:06
サービスインは8時間後だから、それまでに よくしといてねというのが今回の問題ですと。
出場者たちにはAWSのほうに テンプレートが渡されるので、
それを使って環境構築をして、 構築されたサービス、サーバー3台なんですけど、
そのサーバー3台を使って高得点を 出してくださいという問題です。
今回は4,000点ぐらいだったっけな。
ぐらいで、結果何位かと言われると、 出すのを忘れてしまったのでわからないんですけど、
今回4,098ということで普通に低いほう。
ただ失格にならなくてよかったなという感想ですね。
これは実際にAWSの環境に自分で立てて 参加するような形なんですか。
そうです。
ある意味参加条件にAWSアカウントあること みたいなMultitenantなので、
AWSのアカウント複数使うような 感じなんですかね。
サービスがMultitenantという形式を 取っていてって感じですね。
なのでAWSアカウントは1つだけ、 提供されるサーバーも3つだけ。
サービスの中でMultitenantを一応実現されているので、
それをいい感じにスピードアップしてくださいという。
ちなみにチームはどなたと組んだんですか。 どういう方と組んだんですか。
社会人ラインの友人3名で、 私含めで3名でやっていて、
1人は全職の内定者だった人。
入社はしなかった人なんですけど。
いまだにというか、 定期的に連絡を取っているので、
今回のやろうという話をちょっとして、
やりに行って、ちゃんと負けてくるというのを やってきたという感じです。
参加することに意義があるから、 気にしない気にしない。
気にしないはもちろんなんですけど、
これに参加してうまく点数出なかったことに 悔しいと思うのも同じくらい
大切にしないといけないと思うんですよね、 参加した以上は。
そういう思いをするために来たので、
ちゃんと狙ったものをもらって 帰ってきたという気持ちではいます。
06:01
今回はオンラインだと思うんですけど、
参加者同士のコミュニケーションとかって あったりしたんですか。
まず参加中、実施中に関してはないです。
お題連絡を取ることは原則禁止ですし、
Twitter上とかでも問題に関するツイートは してはいけないというレギュレーションになっています。
一応、終わった後、 自分は参加できなかったので、
終わった後とかにDiscordのほうで 参加者同士の話とか、
Twitter上ではそういう話で盛り上がったり していましたね。
あとは結構、自分の周りとかだと、
そもそも出てたんですね、 みたいな人が多くて、自分の周りだと。
結構そこら辺で、出てたんだ、どうだった、 負けたみたいな話を中級として、
負けたというかつらいみたいな話を、 エスキューライトつらいみたいな話をしていました。
なるほど。
CTFだとライトアップ的なものを書く カルチャーがあるなと思うんですけど、
イスコンもそういうのってあったりするんですかね。
結構あると思います。ライトアップという、 ライトアップチックなものですね。
私はこうしました、みたいなことは結構みんな書いていて、
当日のタイムラインを皆さんブログに 書かれている気がします。
イスコン公式に行くとですね、
イスコン中に関連エントリーまとめというところに、
各参加者の感想ブログみたいなのが並んでいて、
結構これがかなりの量あって、
結構これ眺めるだけでも面白いんじゃないかなと思います。
今見ると、ブログ書いたよフォームで投稿できるんですね。
そうです。
じゃあこのままちょっとぬるっと、
次の話題に移りたいんですけど、
SQLiteつらいって話からなんですけど、
これちょっと私が最近ちょっと気になっている、
これちょっと珍しく技術的な話題なんですけど、
Lightstreamっていうフレームワークがあってですね、
これちょっと考え方から面白いなと思って共有なんですけど、
要はSQLiteをプロダクション環境で使っていこうぜフレームワークなんですよね。
強いですね。
いろいろと確かGigazineさんとかでもこのLightstream紹介されていて、
SQLite自体って実はパフォーマンスってそこまで悪いものではないんですよね。
レプリケーション、冗長性みたいな、そういったところ、可用性か、
09:01
そういったところが割とネックになりやすいので採用されないっていうことが多いんですけど、
Lightstreamを導入するっていうか、それは何をするのかというと、
SQLiteのDB、実体ファイルですけど、
これをS3とかGCSとかストレージにバンバンバンバンレプリケーションするっていう、
1秒ごととかに、全部フルでマネージしてやってくれるようなツールですね。
実際これをプロダクションで使ってサービス運用してますみたいなところも、
日本だとあんまり聞かないんですけど出てきてるみたいですね。
これ革命的にすごいのが、やっぱり今まで特に個人で趣味で、
クラウドでサービスを作ろうと思うと、一番料金的にネックになるのがデータベースなんですよね。
安く作ろうとすると、いわゆるNoSQL、ファイアストアとか、
そういったものを使おうかっていう話になりますけど、
結構既存のRDBの仕組みそのまま使えなかったりするんで、
なかなかそれはそれでロックインされちゃったりして、ハードル高いなという話が今まであった。
一方でRDSとかクラウドSQLとかそういうのを導入すると、
基本的にインスタンス立ちっぱなしになるんで、それなりに費用かかっちゃうよねという。
GCPだとちょっと今はどうかわからないですけど、毎月2000円ぐらい確かやってたんで、
ちょっと財布がという感じがあるんですけど、
Lightstreamだと基本的にS3やらGCSやら使えばOKで、
基本的にそれって無料枠5ギガとか確かあったりするんで、
全然その範囲内に収まっちゃうんでデータ自体は。
なのでとりあえずカジュアルにTUDEアプリ作ろうとか、
最初のサービス立ち上げとかで使ってみようとか、
プロダクションユースというよりかは個人で趣味で何か作るっていう時にこういったものを使うと少し堅牢になるみたいな、
そういう一つ選択肢として面白いなと思って、
実はうちの会社の中でもちょっと試験的に使ってみたりして、
非常に良い話をしてますじゃないか。
おだしょー これ面白いですね。
これってちゃんと理解してるんですけど、
S3とかクラウドストレージとかにSQLiteを投げてくれるその中間の役割を見つけて、
その中間の役割になってくれるサーバーが立つってことですか。
12:03
ではなく基本的にサイドカー的な感じでプロセスを動かすような感じになりますね。
どっかであれば、
どっかの例えばランサーバー的なコマンドでサーバー立ち上げると思うんですけど、
その手前にライトストリーム、起動、レプリケーションコマンドみたいなのを打って、
その背後にランサーバーするコマンドを叩いて、
どっちに2つのプロセスを動かすような形を取りますね。
なるほど。
Ubernetesもサポートされていて、
それは確かノード単位でちょっと特別なPodとして、
ノードに対して1台動かすような形でボリュームにくっつけるような形かな。
そこで動くような仕組みだったと思います。
これいいですね。ユニークですね。
結構面白いなと思って。
ゴリゴリリードライトが発生するサービスだと、
というよりかは結構リードが主体で、たまにライトが発生するような、
それこそブログみたいなサービスには結構相性いいと思ってますね。
これいいですね。
今回のエスコンこれ使ったらどうなるのか見てみたいですね。
スキューライトの話題が出て、確かにスキューライトつらいのはわかるけど。
多分今回の目的とこれを入れてもあんま変わらないという気がします。
パフォーマンスが上がるかで言うとちょっと違いますけど。
導入もドキュメントもすごいシンプルで、
実際やってることはシンプルなんで、導入も非常にハードル低いですね。
1個だけ気になってるのが、一応データロスする確率、
確率というか完全にデータが損失しないことは言い切れないらしくやっぱり。
引き込みがあったタイミングでプロセスとかマシンがクラッシュしたらどうなる
っていうところは保証はやっぱりできなかったりするんで、
ちょっとそこだけが気にしてるんで、いわゆるお金扱ったりとかする
ようなセンシティブなところにはまだなかなか僕は使えないなというふうに思ってはいますね。
SQLiteもユースケースによっては全然十分なソリューションだとは昔から思っていて、
特にプロダクションで使うっていうところよりもずれると思うんだけど、
初学者がデータベースそのものを学ぶっていうときには、
まずSQLiteから入った方が教育的効果は高いのかなって。
これは反省として、上の人から若い子にMySQLを教えてあげてくれみたいな感じで、
15:05
ああ、はいみたいな感じでMySQLを教えると、
本来学ぶべきSQLだったりとかデータが入るよっていうようなSQL工夫よりも、
プロセスがどうだとかリモートにアクセスするかとか、
あとクレデンシャルの認証がうんぬんとかっていうのが立ちはだかっていて、
本質を学べないっていうのがSQLiteだとファイルが1個ありますみたいな。
これこそあれですよね、Microsoft ExcelとかMicrosoft Accessみたいな感じで、
そこにあるファイルとデータのやり取りをするオンリーみたいな。
なんか表計算ソフトから1歩上の学びができるみたいな意味では、
学習目的でもSQLiteはいいなって思ってますね。
これなんかRailsとかJangoとかでもそうで、
やっぱMySQL縦でどうこうっていうよりかはもう、
SQLiteで一番最初学習した方が早いっていうのはやっぱ思うところありますね。
Jangoは確かデフォルトSQLiteでくられる。
そうです。
Railsもそうなんでしたっけ?
Railsは今ふわっと言いましたけど、そうだったかは分かんないです。
最初違ったような気がします。
ハードル高いというか、まさにテデさんおっしゃる通り、
本質ないところに目がどうしても最初手をつけちゃううちは行っちゃうので、
SQLiteはその辺も考えなくていいですし、
例えば今回のLightstream使う前提とかにすると、
それこそステージング環境用のDBを作っておいて、
それをそのままローカルにコピーして使うみたいな、
そういったこともできたりするんで、
テストデータ工事したりとかそういう管理も、
割とやりやすくなってるりするのかなっていうのはちょっと考えてますね。
マイスケールを使う場面っていうのも当然あって、
SQLがフィットする場面もあるけど、
やっぱり本質的なレプリケーションを管理したりとかっていうのも、
私はデータベース苦手なので相当高度だと思うし、
やっぱりそういうところからお金を払うことで解き放ってくれるような、
AWSのRDSだったりとかそういうクラウドのマイスケールを
全部お任せ系サービスは本当に素晴らしいなって。
だから段階を経てどこにお金をかけて、
本質だけに向き合うような、
エンジニアの本質だけに向き合うような場作りをしていくっていうのは、
各フェーズで大事だなっていうふわっとしたまとめをしちゃいますけど、
ダメですよね。
ほんとこれホビープロジェクトとかに相性良さそうですよね。
面白いと思いますこれは。
もう1つDBネタはあるんですが、
18:01
時間的にあれなのでまた次回とさせてもらって、
じゃあ小片さんに何か面白いネタというとハードル上がっちゃいますけど、
ネタがあれば。
今日収録しているのが7月の末なんですけど、
Googleがプライバシーサウンドボックスっていう枠組みで、
主に皆さんが注目しているのはサードパーティークッキーを、
Google Chromeで完全にシャットアウトするっていうのが、
当初もっと早い時期にサードパーティークッキー全拒否、
みたいな感じになる予定だったのが、
一旦2023年の夏までに、
夏以降はGoogle Chromeは一切のサードパーティークッキーを送らない、
それまでに開発者の方は頑張ってねっていうのが、
タイムラインが惹かれてたんだけど、
Googleがサードパーティークッキーブロッキングをする上で、
代替仕様、変わりとなる仕様をなかなか開発者さんに提供できなくて、
開発者から全然この状況だと、
2023年の7月以降サードパーティークッキーブロックされると、
めちゃくちゃ困るんだけど、
反発が結構大きかったらしくて、
ちょうど今日ニュースで、
2023年ではなくて2024年に、
1年ぐらい延期しますっていうGoogleの発表がちょうどありましたね。
中村君とかはこのサードパーティークッキーの廃止に関して、
中村君の周囲とかで話題になったりしてますか?
僕は今はそんなにはないですね。
前職が広告に近いようなところを領域としてあったので、
ちょっとウォッチはしてましたけど、
そこからは一回離れてそんなにウォッチしてなかったので、
そうなんだと思いながら聞いてました。
主に広告周りをやってる方。
どっちかというとGoogleも悪質な広告業者に追跡の技術というか、
手段を与えないためにっていう理由で、
サードパーティークッキーをブロッキングするっていう方針を固めたらしいですね。
とはいえ広告だけじゃなくて、
ログイン認証とかの仕組みとかでも、
ドメイン違いのログイン認証とかの仕組みとかでも
サードパーティーとかを使われてるんで、
そういうアプリとかをメンテしてる人にとっては、
21:02
結構大事になっている次第ですね。
以前、私もこのラジオでお話をした、
フェドCMのイベントに出たよっていうのを確か何回か前に言ったと思うんですけど、
そのフェドCMっていう仕様もGoogleが出してきた。
サードパーティーがブロッキングされて困る、
そういうドメイン間の認証連携をするサイトの技術者さん向けに、
フェドCMっていうのを使えばいいよっていう感じで提供される予定の技術。
現在のChromeがバージョン103だけど、
2月先のChrome 105でフェドCMが使えるようになると言われていたんですけど、
フェドCMの仕様も全然固まらない中で、
今回サードパーティークッキー廃止は1年先に延期するよっていう話をGoogleがして、
フェドCMはどうなったんだろうと思って、
さっき食事をしながら見ていたら、
しれっと105ではなく106にっていう感じで延期をしていて、
この人たちしれっとこういうの延期するんだとか思いながら見てました。
無理なものは無理ってちゃんと言うんだな、この人たちも。
周囲の開発者さん、もちろん悪質な広告業者に無実のユーザーさんが追跡されて、
良からぬことに情報を使われるのは良くないんで、
Googleの気持ちも分かるんだけど、
普通に真っ当なドメイン間認証のアプリとかを作られている方とかが、
これに大打撃を受けるんで、
なかなか反発、そういう方々からの反発もあって、Googleの判断は。
ただ1回これ延期して2023年廃止だったのがまた1年延期してるんで、
果たしてサードパーティークッキーは本当に廃止できるんだろうかっていうことを語る方も、
さっきツイッターでサーチしてたらいましたね。
気持ちは分かりますね。
私自身も最近ちょっとやっているお仕事で、
そういうのに関係したアプリケーションの面倒を見ているんですけど、
やっぱり自分自身もこの辺、仕様もぐらぐら動くし、
私もあんまりそういうのに関わって気が浅いんで、
フェドCMって何だろうなとかサードパーティークッキーの大体仕様の中に、
フェドCM以外にもいろいろパーテーションドクッキーとかチップスとかいろんな技術があるんだけど、
そういうのをちゃんと咀嚼して、
ブログだったりとか聞いたのようなところに書いて、
知識ゼロの人たちの知識を引き上げて、
24:02
いろいろディスカッションしたいなとかちょっと思ってますね。
この話は独特で難易度が高いって言ったらちょっとおかしいかもしれないけど、
ちょっと独特な話なので話が広がりそうにないんで、
次の話に行きましょうかね。
何やかんや影響あるっていうのは、
単なる利用者として接点を持たないサイトの方が少ないと思うんで。
話を別にしようって言ってここに留まっちゃうんだけど、
結構2010年、今から10年以上前とかって、
マイクロアーキテクチャだったりとか、
コンポーネント間通信とかして素結合にした方が良い。
それは今も良いんだけど、
いっぱいドメインをサブドメイン作って、
サブドメインに限らずが散らかってきたら、
新しいドメインを買ってきて別のドメインにしてとか、
そういうのが良いとされていた、長らく。
一つの会社の一つのサービスがいろんなドメイン、
全然違うドメインをたくさん持って、
それが故にカードパーティーの締め付けが強くなってきたら、
ドメイン間のログイン、
サートパーティークッキーで裏技チェックに行われているのができなくなってきて、
徐々にログインがうまくいかないみたいなことがあるんですよね。
特にサファリとかは、
Chromeより先んじてサートパーティークッキーが厳しくなっていて、
特にパッと上げると、
ハテナブログとかってたくさんのドメインがあったりとか、
ハテナブログに限らず、
ハテナさんが提供しているドメインでサブドメが違ったりとかして、
そこでハテナにログインしていると、
ハテナブログに飛んでも、
ハテナブログって根っこのドメイン自体が違うんで、
そこの部分で特定のブラウザとか、
特定の画面遷移とかでログインが維持されないみたいな。
それに対してハテナさんのヘルプとかを見ると、
サファニーの場合にはここでサートパーティーを使うというチェックを
ちゃんとオンにしてくださいとかいう書かれ方をしていて。
グッとインな感じなんですかね。
そうそうそうそう。
でもこれも結局ユーザーさんって、
ハテナブログのドメイン、サブドメ選べますよって言っても、
サブドメの数って先に取られたら終わりなんで、
例えば良い文字列、ビジネスとか良い文字列だったら1個取られたら終わりだけど、
27:00
サブドメインのベースとなるドメインが複数選べるっていう風にしておくと、
人気のある文字列とかは別のドメインのサブドメインとしても選べるっていう。
これはサービスとしてはすごい良いんだけど、
そういう風にしてしまったがゆえに、
サートパーティークッキーのブロッキングに対して、
弱いって言ったら誤解があるけど、
ログインの共有とかをしづらい設計になっちゃっている。
結構ハテナさんに限らず、
自社の一つのアプリケーション、
ウェブサービスなんだけど、
複数の、根っこも全く違うドメイン、
サブドメインだったらあれだよね、
クッキーを根っこのドメインドット根っこのドメインで発行すれば、
サブドメ間でドメイン共有できる。
これはファーストパーティーになるんだけど、
根っこも全然違うってなるとサートパーティーになる。
そういう設計をしているアプリがあって、
しかもそれって、さっきのユーザーさんへの便宜を図るために、
いっぱい文字列を選べるようにするとか、
あと、都結合だったりとか、マイクロアーキテクチャーみたいなので、
ドメインをたくさん買ったほうがいいみたいな、
そういうので、
今になってサードパーティークッキーで、
はしごを外されている感があって、
私も頭を抱えるんですよね。
専門的な話でした。
ちょうど、もう一ネタ、大田さんいきますか。
そうだね。
次回に回していいんじゃないかな。
ちょうど30分ぐらいかな。
いろいろとテンポよく話しできた印象は、
正直、一人反省会ありましたという感じなんで、
またどうするかは、また終わったら話しましょうという感じで。
じゃあ、メトロストリーム、ここで仕切りたいと思います。
また次回お会いしましょう。ありがとうございました。
ありがとうございました。
