Gaurunが必要だった背景とプッシュ通知の基本
今回はGaurunという、これはIOS、AndroidのPush通知関連のツールなんですかね。 その話をしていけたらなぁと思うんですけど、
大前提、このGaurunはもうすでにGitHub上でアーカイブされてしまっているんですかね。
そうですね。Gaurunはもともとメルカリが公開していたPush通知をするためのOSSです。
自分も以前メルカリにいた頃にメンテナーやってたんですよ。
けど、今は自分も退職しているし、リポジトリ自体もアーカイブされているって状況ですね。
なるほど。すでに更新はされてないというような状況なんですね。
なんで今さらそのツールの話をしていくんですかね。
この後も話すんですけど、Gaurunを今から使う理由ってないんですよ。
けど、もともとなんでGaurunが必要だったのかっていうのを見ていくと、
PHPから大量のPush通知をするアプリケーションをどうやって運用できるのかっていうのも見えてくるし、
特にiOSのPush通知をするのってAPNsっていうやつと通信しないといけないんですけど、
このAPNsってかなり癖があって独特な部分もあるので、
大量のPush通知をするアプリケーションを実際に運用する時にどうすればいいのかとか、
あと、じゃあ今から具体的に運用するにはどうしたらいいのかってところまで今回踏み込めたらなと思ってます。
なるほど。今さらGaurunを使うっていう形ではないけども、
今からPush通知を大量に裁くしていきたいウェブサーバーだったりとかサービスの場合、
どうすればいいのかみたいなところがGaurunを通じて見えてくるみたいなイメージなんですかね。
そうですね。そういう話をしていければなと思ってます。
はい、お願いします。じゃあどこから話していけたらなと思うんですけど、
まずはあれですかね、もともとGaurunが必要だった状況、どういったところだったのかみたいなのを教えてもらってもいいですかね。
そうですね。たぶんそもそもPush通知ってどうやったらスマートフォン届くのかってところからまず話した方がいいかなと思うんですよね。
そうしないとまず前提がわかんないと思うんで。
なるほど。
Gaurunが作られた当時はちょっと違ったんですが、今だとAndroidはFirebaseCloud Messagingの訳してFCM。
IOSはApple Push Notification ServiceでAPNsっていうやつを使わないとPush通知できないんですね。
それはあれですね、AndroidだったらGoogleのPush通知のAPIがさっきのFirebasePush Notificationでしたっけ?
Firebase Cloud Messagingで、今回FCMって言います。
FCMでAppleのPush通知のAPIがApple Push NotificationService、APNsに当たるっていうような形なんですね。
そうですね。そもそもみんなAndroidかIOS持ってると思うんですけど、まずどうやったらPush通知が届くのかっていうのをちょっと考えて欲しくて、
これってAndroidとIOSも大体一緒なんですけど、まず普通にしててもGoogleのサーバーかAppleのサーバーに通信しに行くんですよ、定期的に。
で、コネクションを作ったらしばらくそのコネクションを保持するんですね。
コネクションが切れたらまた同じことをして、コネクションが極力維持されるようにすると。
で、各アプリを作ってる会社がGoogleとかAppleに対してリクエストを送ると、GoogleとかAppleが代わりにそれを通知してくれると。
そのコネクション経由で通知をしてくれるっていう風になってるんですね。
で、これちょっと気をつけて欲しいのが、AndroidとかIOSアプリの開発やってる人だと、
例えばスマートフォン上の通信を見たくて、ミッドエンドプロクシーみたいなプロクシーを通して通信を覗き見るみたいなことをやる人って言っていると思うんですけど、
実はiPhoneからAPNSの通信ってHPSじゃなくてちょっと変なポート番号なんですよね、実は。
なるほど、一般的な通信ではないっていうところなんですね。
デフォルトだとiPhoneだと5223番ポート、AndroidのFCMだと5228番ポートっていう全然違うポートなんですよ、実は。
つまりそれって暗号化されてないってことなんですかね、通信。
いや暗号化はされてるんですけど、全然違うポートが使われていて、
ただ企業のネットワークとかだと443番ポートしか通信できなかったりとかするんで、
そういうネットワーク帯にいる場合は443番ポートにフォールバックするみたいなことをやったりはするんですけど、
基本的に443番ポートではないので、覗き見るみたいなのはちょっと難しいっていうのは覚えておいた方がいいかなと思います。
ワイヤーシャークとかそういうネットワークを覗き見るツールだと別のポートで出てくるから、ちょっと見るところを変えないといけないみたいなイメージですかね。
そうですね、そんな感じです。
ちなみに443番ポートにフォールバックするのはAndroidとかIOSとかのOSの機能側でおそらくフォールバックしてるっていうようなイメージなんですかね。
そうですね、通信できなかったらフォールバックとしてそっちを使うっていう感じですね。
なるほど、じゃあOSの機能として表示で備わっていて、変なポートがなぜか使われてるっていうようなことなんですね。
そうですね、なのでそこはちょっと気をつけて欲しいところです。
そこでなんでGaolunが必要だったのかっていう、さっきの話になってくるかなと思うんですけど、
そのIOSだったらAPNsっていう、AndroidだったらFCMっていうサービスにそれぞれ通信しないといけないんですね。
で、例えばそのPHPのアプリケーションがあったときに、例えばプッシュ通知をしないといけないですってなったときに、
じゃあAPNsとかFCMに直接通信ができるのかっていうと、実はこの後ちょっと話すんですけど、
まず言うと、GCMっていうGoogleクラウドメッセージングってやつが昔あって、
GaolunはもともとGCMのほうしか対応しなかったです。
で、その後このプッシュ通知のやつがFirebaseのほうに移管されて、FCMっていうのに変わったんですよ。
なんですけど、GaolunはもともとGCMしか対応しなかったです。
で、この後も話すんですけど、FCMは実はもともと2種類あって、
GCMと互換性があるやつと、GCMとは互換性がなくて新しい、さらに機能が増えたやつの2つあって、
Gaolunは残念ながらGCMと互換性のあるほうしか対応しなかったです。
なのでGCMの話もちょっと出るかもしれないんですが、FCMとGCMは一旦Gaolunにおいてはほとんど同じだって思ってもらって大丈夫です。
なるほど、FCMと一口に言ってもバージョンが2個あるっていうような形なんですね。
実はもうちょっとあるんですが、Gaolunに関わるやつだと2つかなっていう感じですね。
その辺もね、ちょっとだんだんこの後話していきます。
単純化すると2つだけど、もうちょっと実際には、具体的にはもうちょっと分かれてるよっていう。
Gaolunの観点だとって感じですね。
結局FCMって実は新しいやつがさらに出てて、Gaolunはそれに対応してないからアーカイブされたっていう経緯があるんですよ。
なるほど、新しい仕様に対応しきれてなくて、対応ができなくなってきたからアーカイブちゃんとしておこうねみたいな、
いうものが内部の中であったみたいな状況なんですかね。
FCMとかまだいいんですけど、ちょっとAPNsがこの後話すんですが、かなり通信が難しいんですね。
そもそも通信するのが難しいサービスになります。
その通信が難しい、さっきのGCMとかFCMへの通信っていうのは逆に簡単なんですか?
Appleだけが難しいのか、それともGoogleの方もそもそも難しいのか?
Googleの方はちょっとめんどくさいだけかなと思いますね、基本的には。
ちょっとめんどくさいっていうのは具体的に聞きたいなと思うんですけど。
Google独自の認証を取らないといけないので、基本的にGoogleのライブラリを使わないといけなかったりとかするので、そこがちょっとめんどくさいってところですね。
なるほど、SDKを入れないといけないってことですね。
基本的にはそうですね。
Googleの、ファイアベースだったらきっとファイアベースSDKをAndroidとかAndroidに入れないといけないっていうような状況ってことですね、API叩くには。
そうですね、サーバー側に必要ってところで。
APSはちょっとね、この後ちゃんと一つ一つ話していかないとわからないと思うんで、この後話していきます。
なんですけど、とりあえずPHPだと基本的に通信が難しいと思ってもらった方が良いです。
なのでそのAPNsは、そもそもPHPから直接叩くのが根本的に難しいって問題があるのと、
あとやっぱりそのFCMとかAPNsが落ちてた時にPHP側が失敗すると、処理が失敗しちゃうとまずいので、そうなるとジョブ級みたいな仕組みでそもそもやりたいじゃないですか。
リトライが可能なようにしたいですよね。
そうですね。なので、とりあえず処理としては成功させて、その後に図書通知を送りたいと。
で、ガウルンはそれもやってくれるんですよ。
そのジョブ級、HTTPでリクエストを受け付けて、内部でとりあえずジョブ級で積んでおいて、それでその後APNsとかFCMに対してリクエストを送る。
ということをやってくれるのがガウルンです。
ここでちょっとガウルンの構成要素みたいなのを聞いてみたいなと思うんですけど、ちょっと大前提として必要な知識になってくるかなと思うんですが、
ガウルンはウェブサーバーとして動作するツールですかね?
そうですね。HTTPサーバーが立っていて、HTTPのAPIがあります。
なのでアプリケーションからHTTPのAPIでリクエストを送ると、内部的にジョブ級で積んでくれて、それが実際にプッシュ通知されるというふうになります。
バックエンドでガウルンが一回プッシュ通知の内容をPHPだったりとかいろんなサービスから受けて、
ガウルンの内部で一旦AppleとGoogleの方にAPIとして通信するみたいなことを中継してくれるようなサーバーということですかね?
そうですね。
理解できました。
そのガウルンの中でいろいろFCMだったりAPNsを呼び出しているところの話にどんどんなっていくんですかね?
APNsのHTTP/2・接続維持・IP制約
そうですね。FCMはまだ普通のAPIなんですが、今回ずっとAPNsの話をしていくかなと思うんですけど、APNsがだいぶ厳しいんですよ実は。
具体的にどう厳しいのか一つ一つ話していくと、まずAPNsはHTTP2しか話せないサーバーです。
なるほど。このヤオヨロズのOSSを過去回とかを聞いてくれてる人だったらなんとなく理解してくれるかなと思うんですけど、HTTP2だけの通信みたいなのって結構厳しいですよね。
これ本当特徴的なのは普通のWebサーバーってHP2が使えなかったらHP1.1にフォールバックするんですけど、APNsはHP2しか話せません。
HP1.1は話せないです。
フォールバックしてくれないんですね、Appleのサーバーは。
フォールバックっていう仕様がそもそもないですね。
ちなみにそこなんでなのかみたいなところって知ってますか?
なんでなのかは自分もよくわからないんですけど、多分Apple側が運用しやすいんだと思うんですよ。
なんでかっていうと、APNsはここもガウルンが必要な大きな理由の一つなんですけど、コネクションを保持し続けないといけないんですよ、仕様として。
それはクライアントとのコネクションですかね?
サーバー側とAPNsの間でコネクションを保持し続けないといけなくて、コネクションを作ったり切ったりしてるとバーンされちゃうんですよ、実は。
そういう仕様がそこですね。
APNsに厳密なレートリミットが決まってるわけじゃないと思うんですけど、そのコネクションを極力保持してくださいっていう。
コネクションを切ったり作ったり繰り返してたらバーンしますみたいなサーバーなんですよ、APNsって。
すごい特殊ですね。
できる限り長く保持しておかないとバーンされてしまう。
しかもサービス特性上、プッシュ通知がバーンされるとかなり厳しいですよね。
サービスによると思うんですけど、かなり厳しいですと。
なのでコネクションを保持し続けないといけない。
HP2は基本コネクションを保持するっていう仕様なんで、HP2だとコネクション保持しやすいっていうのがあるんですよね。
なので、要はHP2がまともに使えるアプリケーションで通信しなさいってことなんですよね。
なるほど。ウェブサーバーの方の開発言語も若干縛りがあるみたいなイメージなんですね。
多分縛りたいんだと思うんですよ。
PHPってリクエストの度にコネクションを切るじゃないですか、使用として。
そういう言語を多分締め出したいんだと思うんですよ、APNsって。
毎回リクエストしてくるなよというような言語を締め出したいと。
そうですね。
なるほど。
なのでこれがガウルンが必要だった大きな理由なんですね。
結局PHPから直接通信するのが結構不可能。
HP2だけだったらデフォルトだとできないんですけど、HP2だけだったら通信するウラウザみたいなのはあるはあるんですけど、PHPから。
けどコネクションを保持し続けるっていうのは基本的にできないので、APNsはコネクションを保持し続けないといけないんですよ。
だからPHPとは分けたかったっていうのが一つの理由です。
このガウルンができた理由の一個が当時メルカリがPHPウェブサーバーで使っていて、そこからAPNsにコネクションを張り続けるということが技術的に少し厳しかったので、ガウルンという中継サーバーを立てざる得なかったという。
そうですね。
なるほど、理解できました。重要というか一番最初のモチベーションが。
これだけじゃなくて、IPアドレスもあるんですよ。実はレートリミットみたいなのがAPNsって。
IPアドレスを変えてしまってはいけない。
いや、一つのIPアドレスから通信できる量に限りがある。APNsは。
量というのはどのデータ量?
レートリミットみたいなのが多分あって、その回数とかで、なんか厳密なレートリミットは決まってるわけじゃないんですけど、
大量にプッシュ通知を送ろうとすると、一つのIPアドレスからだと送れないんですよ。APNsって。
プッシュ通知の特性上、サービスによるとは思うんですけど、大量のクライアントに一気に配信するみたいなのが一般的なプッシュ通知の使い方なのかなと思うんですが、
そのデータ量に関しては、プッシュ通知の種類がいっぱいだとバーンされるというか、
基本的にはクライアント数ですね。
クライアント数でもう引っかかってしまうんですね。
そうですね、基本的には。
デバイス数ですね。
デバイス数、素材のたくさんのデバイス数に対してプッシュ通知を送ろうとすると、一つのIPアドレスからだと基本的には送れない。APNsの場合。
それがIPアドレスごとなんですね。
そうですね。
なので、一般的なウェブアプリケーションだと、多分グローバルIPアドレスってサーバー付けないじゃないですか。
はい。
なので、基本的にはNATとか通ると思うんですけど、例えばガオルンがNATの配下にいてってやっちゃうと、そのIPアドレス基本的に1個になっちゃうと。
そうなると、APNsに対しては大量のプッシュ通知って送れないんですよ。
1個になってしまうから、デバイス数制限が発生してしまうからですね。
そうですね。なので、実際にはガオルンは1台1台グローバルIPアドレスが付いているインスタンスで1台1台立って運用されていたっていうのが実態です。
ガオルンの1個1個のインスタンスにIPアドレスが触れるような構成になってないといけない。
ガオルンというか、そのIPプッシュ通知、APNsにリクエストするサーバーが複数のIPアドレスを持っている構成になっている必要性があるんだけど、そんなものはWebアプリケーションかなり厳しいので。
まあできなくはないけどね、そういうのも。
それよりは普通に1台1IPアドレス、グローバルIPアドレス1個付けて複数台で運用した方がシンプルにはなる。
っていう理由でガオルンとして切り出してるっていう。
そうですね。なのでガオルン専用のプッシュ通知専用のグローバルIPアドレスが付いているサーバーを用意してそこにガオルンが1台ずつ立っているっていう構成で運用してたんですね。
こうしないとAPNsに対して大量のプッシュ通知を送るっていう構成が作れないんです、実は。
そもそもできないんですね。
そもそもできない。
ちなみに具体的に実際その障害、ガオルンを使う前かな、で起きた障害とかってあったりするんですか、このプッシュ通知が。
その時はちょっと自分がいなかったので、その辺は知らないですね。
じゃあガオルン立ててから片杉さんが運用、携わるようになったという中で、ガオルン立てた上でも何かこう問題とか発生してなかったんですかね、実際。
大きな問題は基本ないかなと思いますね。基本的にグローバルIPアドレス立てて、ちゃんとガオルンってGoで作られてるんですけど、GoみたいにちゃんとHP2が使えてかつコネクションが保持できる言語で作れば基本的にはなんとかなるっていうのがAPNsです。
なるほど。APNsの問題点って使いづらいところって今挙げてくれたところだけなんですかね、他にあったりしますか。
いやまだあるんで、どんどん話していかないといけないんですけど。
GoのHTTP/2実装と認証更新
この単純なHP2だけかっていうと、実はAPNsってそうじゃなくて、APNsは複数やり方あるんですが、一つは証明書、独自の証明書を作って、その証明書を持ってないと通信できないんです、そもそも。
証明書というのはApple…
Appleが発行する証明書を使った通信をしないといけない。
Appleから発行された証明書をガウルンみたいなWebサーバー、プッシュ通知を送るアプリケーションサーバーに設置しないといけないってことですかね。
そうですね、ガウルンの中で証明書を持ってないといけないんですよ。
HP2の通信をする時にも独自の証明書っていうのを持ってないといけない。
実は、GoのHPクライアントって、こういう証明書とかこの辺の設定いじるとHP2使えなくなっちゃうんですよ。
それは言語特性上そうなんですか。
言語のライブラリーの特性上ですね。
HP2を有効にしていいかわからない状況で有効にしちゃうとトラブルになるかもしれないので、デフォルトだと変な設定すると無効になるんですよ。
それは当時使ってたGoのモジュールとしては、普通の標準のHTTPモジュールとかではなかった?
Goの標準のHPクライアントですね。これは今もそうですね。
そういう仕様なんですね。
Goの標準ライブラリーのHPクライアントの仕様として、この辺の設定いじるとHP2は使えない。
なので、普通のGoのコードを書いちゃうとHP2有効にならないので、APNsと通信はできないです。
じゃあそれどうやったんですか。
当時としては、Goの純公式パッケージでHP2のパッケージがあるので、それを使えば一応HP2無理やり有効にすることができるので、それで無理やり有効にもともとしてました。
なるほど。デフォルトでは使わずにちょっと手を入れて、
純公式のライブラリーを使ってたんですけど、ここからガウルンの内部実装の話ちょっとずつ入っていければと思うんですけど、
実はこれ、自分がいろいろやってたんですけど、ちょっとこれ実はトラブりました。この辺の実装。
トラブったとは具体的にはどういう?
そもそもこれちょっとすごいややこしい話なんですけど、GoのHP2の対応って、
もともとブラッドフィッツっていうGoの作者でもあり、HP界隈とかでも結構すごい有名な、もともとメビキャッシュリーの作者でもあるんだけど、
ブラッドフィッツっていう人が、もともと趣味でHP2のコードを書いてたんですよ。Goと関係なく。
そのブラッドフィッツが趣味で書いていたHP2のコードが、なんか純公式パッケージみたいになって、
GoのHPクライアント自体でHP2対応しようってなった時に、
もともとブラッドフィッツが趣味で書いたコードを純公式パッケージにして、その純公式パッケージのコードそのまま入れたらいいじゃんってなったんですよ。
この時にバンドルっていうGoの独自のツールみたいなのを作ってて、
その純公式パッケージを無理やりGoの標準ライブラリの中に無理やり組み込むみたいな、
基本的にはコードをコピーして、その関数名とかちょっと微妙に変えてコピーするみたいな仕組みなんだけど、
っていうすごい独自の仕組みが動いていて、だから純公式パッケージの、
XNetHP2ってやつなんですけど、このXNetHP2とほぼ同じコードが実はGoの標準パッケージの中で動いているんですけど、
ただ一応関数名とか全部違うんですけど、ほぼ同じ実装が動いていると。
なるほど。作者である方が作っていた、趣味で作っていたライブラリが、
中はなんとなくではないと思うんですけど、流れで標準パッケージの中に入ってしまって。
そうです。いろいろ意を曲折あって、結局内部にコピーされてるんですよ今。
なので、けどHP2無理やり有効にしようとすると、XNetHP2のコードを無理やり呼ばないといけないんですけど、
これがバージョンアップサポってたんですよ一時期、Gaolunがこの辺りの。
XNetHP2はこのバージョンで使われているXNetHP2の実装みたいな感じで対応付けがあるので、
実はGoのバージョンとXNetHP2のバージョンは合わせてないと何が起こるか分からないんですよね。
要は誰もテストしてない状況になるから何が起こるか分からない状態になるんですよ。
内部実装がずれてしまう可能性があるってことなんですね。
なので、それのせいでGoのバージョンアップすると壊れるよって報告が昔上がったことがあって、
その時は自分たちはGoのバージョンアップしてなかったから問題なかったんですけど、
一周でバージョンアップしたら壊れるよっていうのが上がったことがあります。
Gaolunの一周でGoのバージョンを上げたら壊れたんですけど。
あっていうのが今も残ってるんですけど、っていう一周がついたことがあります。
これに対してどうやったかっていうと、1.13だったかな。
この頃ちょうどGoのバージョンアップで、これちょっと微妙ではねって話があって、
Force Attempt HP2っていう設定が入りました。
NetHTTPに。今もちろんあるんですけど。
無理やりHP2を有効にするっていう設定が入ったんですよ。
なので、Xnet HP2使わなくてもHP2を無理やり有効にすることができるようになったので途中から。
なのでそれを使うことで、Xnet HP2の依存自体を剥がすっていうのを昔やりました。
標準パッケージだけで事足りるようになったと。
そうですね。もう1.13から。
それでやっと標準パッケージ使わなくても、一旦APNsと通信できるようになった。
めでたい話じゃないですか。
っていうのが証明書のやつなんですけど、ただこの証明書って1年に1回更新がいるんですよ。
Appleからの発行された証明書の更新作業が必要。
そうです。Appleのサイトで発行できるんですけど、1年に1回手作業で直してたんですけど、大変じゃないですか。
めちゃくちゃ大変。具体的にはAppleデベロッパーコンソールとかにアクセスして、
証明書をどんどん出してってことですよね。
確かそうなんですけど、もう1個方法があって、トークンベースドアンティケーションってやつがあって、
証明書というかプライベートキーみたいなのをAppleのサイトで発行できて、そのプライベートキーでJOTを発行すると。
そのJOTを発行して、Authorizationヘッダーにつければ通信ができると。
それで良くないですか?
このプライベートキーは更新いらないんですよ。ずっと使える。
というのが、途中から使えるようになったんで。
ガオルン最初作った時は使えなかったんですけど、途中から使えるようになったんで。
これ自分が対応したんですけど、トークンベースドアンティケーションも使えるように途中からして、
それで証明書の更新しなくて良い形にしました。
めちゃくちゃいいですね。もうエクスパイアしないんですね、これで。
ただ、これもめんどくさくて。
確かにJOTの有効期限が3600秒とかだったかな。1時間くらい。
APNsはさっき言った通り、コネクションを何回も切ったり付けたりするなっていうルールじゃないですか。
このJOTも頻繁に作っちゃダメなんですよ。
頻繁に作るとバンしますみたいな感じになってるので、
確かにガオルンは3000秒くらいで再生するみたいな処理をやってるんですけど、
そういう処理も結局、ゴーだから内部で残り少なくなってきたんで更新しますとか、
そういう処理は割と簡単に書けるんですけど、
ゴー以外の言語だとこういう処理って言語によるけど書くの難しかったりするじゃないですか。
そうですね、バックグラウンドの処理みたいなことですかね、具体的に。
そうですね。
めんどくさいけども、ゴーだったらいい感じ。
ゴーだったら簡単にできるんですけど、
なのでそのAPNSは仕様として、ゴーだったら別にいいけど、
ゴー以外の言語だとこれどうするのみたいな仕様がめっちゃたくさんあるんですよ。
なるほど。
ちなみにちょっと話戻って、さっきの3000秒のトークンエクスパイアの話なんですけど、
3000秒でコネクションが切れるのは問題ないですか?
厳密なルールが決まってるわけじゃなくて、
APNSはサーバーに負荷かけるなみたいな感じなんですよ。
なるほど。
だからコネクションも、
真摯協定的な。
そうですね。
コネクションをブチブチ切るサーバーはこっちは切るぞって言ってくるし、
ちょっとも何回も何回も発行しまくってたら切るぞって言ってくるし、
なるほど。
とにかく難しいんですよ、APNSは。
だからこそレートリミットとかそういうのが明示されてないんだけども、
やりすぎるといつか来るぞというようなことなんですね。
難しいですね。
そう、このあたりがね。
だからAPNSはめちゃくちゃ癖強なんですよ。
運用してみないと分かんないところ多いですね。
どのぐらいだったらいいのかなみたいな勘どころも分かりづらいですもんね。
でもね、ギリギリ攻めない方がいいですよ。
安全側に。
変えがないんで、APNS使う以外の方法ないんですよ。
iOSにプッシュ通知する方法って。
口がないですよね。
だからAPNSにバンされるともうお手上げなんで。
だからAPNSの起源は絶対損ねない方がいいんですよ。
Appleさんの起源は損ねるなと。
そうするともうiOSに対して一切プッシュ通知できなくなるので。
それはそうですよね。
というところなんですよ。
運用に関しては安全側に立ちた方がいいというところですね。
そうなると、Goで極力コネクションも保持するし、
Jotとかも極力発行しない極力使いますとか、
そういう色々工夫が必要になってきます。
それがGoだったらめちゃくちゃ書きやすくなってくる。
Goだったら簡単ですね。
簡単といっても、あんまり普段書かないようなコードを書かないといけないから、
結構めんどくさいはめんどくさいんだけど、って感じですね。
なんか特殊なことをやってますもんね。
APNSの通信周り。
APNS自体がだいぶ特殊なサーバーなので、
あまり見ないコードを書かないといけないですね。
ちなみに、当時で全然構わないんですけど、
今だったらもしかしたらあるかもしれないんですけど、
Goのモジュール、ライブラリーで、外部のライブラリーで、
APNSの通信周りをやるみたいなものってなかったんですかね?
いくつかありますよ。
いくつかあって、ガオルンは結構参考にしたりとか、
一部ライブラリー取り込んだりとか、そういうのもやってましたね。
参考実装がありつつってことなんですね。
そうですね。そういうのは随時見たりしながらやってましたね。
追従していきながらということですね、ガオルンで。
ただ、自分プレリコ送ったりとかしたんですけど、
一部並行プログラミングがバグってたりとか、そういうのはありましたね。
やっぱり難しいところですね。
そうですね。あれこれ、並行プログラミングできてないじゃんとかあって、
プレリコ自分が送ってマージされたりとかっていうのはあったので、
結構この辺りはちゃんと見ないと結構難しいところですね。
デバイストークンとGaurunの運用構成
そこら辺のテストってどうしてたんですか?
実際にAPNSにリクエストを送るしかないかなと。
そうですね。APNSに直接リクエストを送るしか多分ないですね。
GoだとHPAPIのテストとかする仕組みってあったりするんですけど、
APNSの場合、そっちじゃないんですよね、めんどくさいのって。
どこなんですか?
そもそもその証明書がないといけないとか、
そもそもサーバー自体が特殊だから、そっちのテストはちょっと現実的じゃないですね。
Mockサーバーを用意するのがめちゃくちゃ大変みたいなことですかね。
Mockサーバー自体が結構めんどくさい。
実装するのが大変だよって。
そうそうそう。
なので、実際に動かすしかないんじゃないかな、APNSに関しては、と思っています。
じゃあ、ガールンを担当してた時って、実際に書きましたとアップデートしますと、
その時には基本的なテスト、最終的なテストはステージング環境みたいな感じでしたか?
もちろん自分の手元で、自分のiOSアプリとかAndroidアプリに対して
図書通知を送って、送れたらステージング環境で実際にデプロイしてみて、
問題なかったら本番って感じですね。
結構ビジネスクリティカルなところでも、
メルカリだったら結構ビジネスクリティカルかなと正直思うんですけど、
かなり重要な部分ですもんね、ここ。
そうですね。図書通知が来ないと荷物を送り忘れちゃったとか、
そういうのが起こるので、かなりクレームがつながるんですよ。
なので結構ミッションクリティカルではありますね。
なるほど。ちなみにAPNsで他の困りごとというかめんどくさいポイントはあったりします?
まあ、そもそも根本的に色々難しくて、
アプリが最初に、例えばアプリインストールした時とかに、
デバイストークンが発行されて、それをリクエストで送られてくるんですね。
アプリのインストールをした初回起動時みたいなところですね。
そうですね。基本的に初回起動時に送られてきて、それをサーバー側に保存しておくと。
基本的にそのユーザーがどのアプリを、
例えばアプリをある程度使って、1年後に2年後に新しいアプリ買い替えましたってなると、
基本的にどんどん溜まってくるんですよね、デバイストークンが。
新しいiPhoneを買ったとか、新しいAndroidのデバイスを買って、
デバイス自体が変わった時ですかね。
そうですね。それをもう全部送らないといけないんですよ。
そのユーザーに紐づいているデバイストークンに対して一応送っておかないといけないっていうことですかね。
そう、全部送って、それで届いた、届いた、届いたみたいな感じになるって感じですね。
実際その古いデバイスはもう使ってないかもしれないけども、送っておくしかないみたいな。
送るしかないですね、こっちからすると。
っていうので、だからアプリケーションがガートガウルンにリクエスト送ってきて、
ガウルンはこれちゃんとジョブ級にしないといけなくて、
かつ失敗した時とかに失敗とか、あとガウルン自体が再起動とか、
そういう時のためにファイルに実際書き込んだりとかするんですけど、
一旦テンポラリーに残していくんですね。
で、成功したらOKみたいな、そういうの頑張ったりとか。
なんかね、そういうジョブ級を、そもそもこれファイルで書き込んでるって時点で、
これコンテナー化とかできないんですよ、ガウルンって。
コンテナー内のファイルをいじることができないから。
コンテナーって基本ファイル使えないじゃないですか。
なので、そもそも前提としてコンテナーじゃないんですよ、ガウルンって。
この辺がガウルンがアーカイブされた理由の一つだと思うんですけど、
なのでちょっとまあ一昔前のアーキテクチャーっていう前提でやってますね、ガウルンは。
そこなんでレリースとか使わなかったんですかね。
ファイルに書き出すというアーキテクチャーになってたんですかね。
サーバーごとにジョブ級を使っていたので、
作ってやっていたっていうのがありますね。
あととにかく高速に動かないといけなかったっていうのもありますね。
依存、ミドルウェアの依存をできる限り少なくしたかったとかそういうのもあったりするんですかね。
多分そうですかね、なんか当時の判断はそんなに詳しくないですけど、
当時オンプレでやってたんで、多分そんなに依存ミドルウェアを増やしたくなかったんじゃないかなとは思いますね。
コンテナというのが大前提なかったってことですね。
当時はコンテナという前提なかったので。
考え方として設計の考え方としてまだ。
その後また話すんですけど、今から一から作るんだったらジョブ級のミドルウェアとか使ってどんどん送るとか、
それ他の手段はあるだろうなと思いますね。
なんか絶対もっと他の方法あるだろうなと思いますよね。
そうですね、ただ結局APNSに関しては今言ったやつ全部やらないといけない。
要はグローバルIPアドレス持ってないとダメだよねとか、コネクション保持しないとダメだよねとかって今言ったやつは全部やらないといけないですよ。
そこの実装変わらない基本的に。
あとちょっと気になったのが、デバイストークンがどんどん増えていくって話がさっきあったじゃないですか。
どんどん増え続ける限りかなと思うんですけど、右肩上がりかなと思うんですけど、デバイストークン数は。
それってどうやって分散させてたんですか、IPアドレスごとに。
いや、分散しないですよ。
分散してなかったんですね。
普通にリクエスト送って全部ガウルン受け取って送るってだけ。
でもそれでレートリミットが、レートリミットではないけども。
サーバーがたくさんあるんで、それぞれのサーバーがそれぞれのガウルンで通信してって感じですよ単純に。
ガウルン、ウェブアプリケーションサーバーに一対一に存在するガウルンのインスタンスが存在するっていう意味ですか。
いや単純にDNSキャッシュですね。
DNSキャッシュ。
DNSで解決して、解決したやつでしばらく送ってDNSキャッシュ切れたらまたDNS解決して、でどれかって感じですよ単純に。
なるほど、じゃあ毎回というかそのキャッシュが切れたら違うサーバーにランダムで割り当てられるという。
そうですね、アプリケーションサーバーがたくさんあるからある程度分散するんですよ。
完全にきれいに分散したわけじゃないんで、ある程度分散されてれば良いって感じですね。
じゃあそのランダム性に若干任せて分散できてるよねみたいなところか。
そうですね、でもどうだったっけな、なんかね色々仕組みがあったんで、もしかしたらエンジンXでプロクシーして分散してたかもしれないですね。
この手の似たような仕組みがたくさんあって、どれがエンジンX通してどれがエンジンX通してなかったかあんま覚えてないんですけど、可能性としてはDNSキャッシュで分散していたかエンジンXでプロクシーパスで分散していたかのどっちかだと思いますね。
なんかすごい厳密にやろうとするとデバシストークの数ごとに分散させないといけないのかなと思っちゃうんですけど、
そんな厳密にしなくて大丈夫ですよ。ある程度分散されていれば。厳密にレートリミットの数が決まってるわけじゃないんで、ただ大量に1台から大量に送ると詰まりますよっていう話なんで。
単純にそのガウルンサーバーが1個だけだったら1個のIPアドレスだけだったら詰まるよねっていうような話だけでってことですね。
いっぱい持ってたら大丈夫だよねって。
そうですね。
理解しました。で、その中で他にAPNsは。
APNsは一旦こんなところで。
そんなところなんですね。
FCM HTTP v1とGaurunの限界
この後また話すんですけど、FCMの話、Googleの方のファイアベースの話をしていくと、FCM自体は割と普通のHPAPIで、認証周りがGoogleの認証なんでちょっと特殊なんですけど、
そこさえやればHP1.1も使えるし、普通のAPIですと。
たださっきもちょっと言った通り、GCMと互換性のある方は今FCMレガシーとかって呼ばれてるのかな。
こっちは今もう送信できなくなってます。
で、ガウルンはこっちしか対応しなくて、実は自分が新しいFCMの方に対応したプレイケースを作ってるんですけど、
そっちは結局マージされてなくて、当時としてはそんなに需要度高くなかったんでマージしなかったんですけど、
というのもあって、今のガウルンは結局動かないんですよ、今からは。
Androidの方は動かないってことですね。
Androidの方は今動かないですね。
しかもGCMの互換の方の古いFCMだと色々機能が足りないんですよね。機能が少なめです。
というと。
例えばそのタイトルっていうのがあって、なんかそのプッシュ通知がタイトルとボディで2つに分かれるように新しいFCMだとなってたりするんですけど、
それも使えない。タイトルの設定とかできないし、あと画像の設定とかもできない。他にも色々機能があってその使えないんですよ。
メタデータが足りないんですね。
メタデータが、単純に指定できるメタデータが少ないですよね。
なのでこの辺、使える機能がそもそも少ないっていうのがありましたと。
はい。
で、そのFCMの今だとHTTPv1っていう新しいやつしか対応しなくて、
これを真面目に使うとすると、ファイアベース、さっきもちょっと話したファイアベースアドミンSDKってやつを使って送ることをしないといけないと。
ファイアベースアドミンSDKを使わないと送れないってことですね。
で、ガウルンはその自分がプレリクエストは作って今もあるけど、それは結局マージされなかったと。
っていうのがあります。
新しい方は。
そうですね。で、そんなところかな。
FCMによるAPNs統合と中国での課題
で、FCM、ここからね、じゃあ今からガウルンはとりあえず使えないとして、今からそのプッシュ通知の仕組み作るとしたらどうなんの?っていう話をちょっとずつしていこうかなと思うんですけど、
実はFCMってAPNsも扱えるんですよ、実は。
めちゃくちゃ便利じゃないですか、もう。
そのファイアベースすごくて、APNsトークンでファイアベースを使ってなんとできちゃいます。
なんで全部FCMでやるってことが実はできちゃう。
じゃあ開発者としたらファイアベースに対してリクエストをすればAppleのプッシュ通知も使えてしまうと。
使えちゃうんですよ。けどちょっとめんどくさいのが、そのトークンの扱いで、多分一番推奨されているのが、
iOSアプリにそのファイアベースのSDK組み込んで、で、iOSアプリから直接ファイアベースのトークンを発行すると一番楽です。
iOSアプリのライブラリとしてファイアベースのクライアントSDKをインポートして、
で、そこからファイアベース経由でプッシュ通知を実装してしまうというようなことですかね。
ファイアベースのトークンを発行するって感じですね、そこから。
結局プッシュ通知自体はAPNsから送られるんですけど、そのトークンが、APNsのトークンを直接扱えないので、
ファイアベースのトークンである必要があるんですよ。
なるほど、Appleの方が発行するデバイストークンではないんですね。
ではない。なんだけど、これは致命的な欠点が一個あって、
中国がGoogleのサーバー、GoogleのIPアドレスアクセスできないんですよ。
できないですね、Great Firewallで。
そう、Great Firewallがあるのでアクセスできないんで、これをやっちゃうと中国の人はプッシュ通知を送れなくなります。
なるほど、中国から中国のローカルにあるデバイス上ではプッシュ通知を受け取れないということですね。
ファイアベースに通信できないからファイアベースのトークンが作れないと。
なるほど。
そうなるとプッシュ通知を送れないという致命的な欠点があります。
逆にApple公式IPNsだったらプッシュ通知を送れるってことですかね。
だからIPNsを直接使えば中国でもプッシュ通知できます。
ファイアベースに通信ができないってだけですね。
そうですね、実はこれ一個裏技があって、今だったらAPNsトークンをFCMのトークンにサーバー、こっちのサーバー上で変換することができます。
ちょっともうちょっと具体的に言ってもらってもいいですか、その変換ができるという。
サーバー側で変換できるんですよ。今言ったのはiOSアプリにファイアベースのSDK組み込んでた話だったけど、
そうじゃなくてそのサーバー側、サーバー側で変換ができるっていう仕組みが実はある。
Webアプリケーション側で一旦iOSのデバイストークンを受け取りますと、アプリのインストールした時に。
そのデバイストークンをファイアベースのトークンに変換することがWebアプリケーション側からできるっていう。
今だったらできますね。
いいじゃないですか、それ。
そうなんで、それを使えばそのAPNsを普通に受け取って、APNsのトークンを普通に受け取った後にファイアベースのトークンにこっちで変換して、
ファイアベース経由でAPNsの都市通知を送るっていうことができる。
そうするとさっきから言ってるAPNsのめんどくさいやつとか全部無視して、
ファイアベースにとりあえず送れば全部ファイアベースが何とかしてくれるっていう構成が実は作れる。
今だったら。
その場合はWebアプリケーションが通信するのはファイアベースのFCMじゃないですか。
FCMに対してプッシュ通知を送るじゃないですか。
プッシュ通知をリクエストするじゃないですか。
そこからGoogleのファイアベースのサーバーからAppleに通信が行って、
Appleのネットワーク経由でプッシュ通知が送られるっていうような理解だったんですかね。
iOSアプリにプッシュ通知できるのはAPNsだけなんですよ。
ファイアベースから直接いけないんですよ。
ファイアベースはAPNs叩いてるだけなんですよ。
なるほど。
さっきの中国のGreat Firewallで弾かれるっていうのは、
そもそもファイアベースへリクエストができないから、
ファイアベーストークンをデバイス上で発行することができないっていうことですね。
そこでクライアント側で弾かれて、前段で弾かれてしまってるからプッシュ通知ができないってことですね。
そうですね。
なのでサーバー側で発行しちゃえばプッシュ通知実はできちゃいます。
便利ですね。
全部サーバーの実装はファイアベースの任せで、
ファイアベースの一貫性というか、ファイアベースに対してリクエストすればいいだけと。
なので今からやるんだったら、
もう全部APNsは無視して、全部ファイアベース経由でプッシュ通知しちゃうと。
中国に対応したい場合は、
もうAPNsのトークンからサーバー側でファイアベースの方で変換して、
そこ経由で送るって手が、今だったら実はできちゃうんですよ。
ただ残念なお知らせがあって、
このAPNsのトークンをFCMのトークンに変換する仕組みっていうのが、
これがマイグレーション用なんですよね。
なるほど。
なのでそのファイアベースに移行してほしいから、今だけ用意してますみたいな扱いなんですよ実はこれ。
テンポラリーな実装と。
なのでこれ実はデプリケーテッドになりそうなんですよね。
確かなってない、今まだデプリケーテッドになってないんですけど、
ただその周辺ツールとかデプリケーテッドになってるので、
基本的にはこれ自体もデプリケーテッドにこれからなる。
その口が閉ざされる可能性があると。
可能性が結構高い。
なので今からやるんだったら、今だったらFCMに全部統一するのが間違いなく一番楽。
なんだけど将来的にずっとそれでいけるかはちょっと怪しいっていうのが今です。
なるほど。ちょっと微妙な移行期みたいなところで、
なんだけど基本路線はファイアベースのSDKをクライアント側に組み込むっていうのが一番簡単な道ってことですね。
ファイアベースは基本そっちでやってくださいって言っていて、
そっちでやれればサーバー側の実装はすごく楽、
そのFCMだけ通信すればよくなるんですごく楽になります。
Topic配信と現在の選択肢
しかもFCMはもっとすごいやつがあって、
これねトピックってやつが使えるんですよ。
トピックどういう機能ですかね。
そうですね。
さっきもちょっと言ってた大量の人にプッシュ通知を送りたいみたいなケースで、
ガオルンだと大量の人にプッシュ通知を送りたい場合は、
例えば100万人にプッシュ通知を送りたいなったら100万回リクエストを送る必要があるんですよ、ガオルンだと。
それはデバイストークンごとにリクエストを送る必要がある。
そうですそうです。
ってことですかね。
トピックはアプリ側で、アプリじゃなくてもサーバー側でもできるんですけど、
そのトピックっていうのを設定しておくと、
そのデバイストークンに直接送るんじゃなくて、
設定されたトピックに対して一気にプッシュ通知を送れる。
だから、例えばアプリ全体にトピック設定しておいて、
そのトピックに送れば全員に対して一気にプッシュ通知を送るっていうのが簡単にできる。
データ構造的にトピックに対してデバイストークンが紐づいているようなイメージですよね、複数の。
そうですね、一つのトピックに対して複数のトークンが紐づいているみたいな形になると。
なので、そのトピックに対してどんと送ればできるし、
あと物によっては、例えばどこにどういう興味があるとかでトピック付けとけば、
その興味がある人にだけ一気に送れる。
デバイストークン一個一個やってると、一個一個リクエスト送らないといけなくなるから一気に送れないじゃないですか。
どうしても時間かかっちゃうんだけど、トピックで一気に送っちゃえば一瞬でガンと送れる。
サーバー側のリクエストとしては一本になるということですね。
それがトピックっていうのを使うとできちゃう。
便利ですね。
これがめちゃくちゃ便利。
なんとなく今までの理解してた、ガウルもそうなんですけど、
デバイストークンを一個に対して1リクエストみたいな形になってるんですね、プッシュ通知の実装として。
基本的には1デバイスに対して1回リクエストを送らないといけないんだけど、
トピックを使えば一気にいろんなデバイスに対して送れる。
まとめられるし、さらに地域だったりとかそういうメタデータによってグルーピングもすることができるっていうのがトピックっていう機能。
そうですね。
ただ、1つのアプリケーションに対して設定できるトピックって2000個くらいかな、最大で。
上限が決まってるので、何でもかんでもトピックにすりゃいいってわけじゃないんで、
だからある程度絞ってピンポイントピンポイントでトピック設定しとくとすごく便利。
これすごいのがFCM、APNSに対してもトピックが使えるんですよ。
便利ですね。
だからAPNSって基本的にトピックとかないので一気に送るってことはできない、APNSは。
一件一件送るしかないんだけど、なんとFCM経由で扱えばトピック使うと、
実際FCMは一個一個送ってるはずなんだけど、使ってる側は一切意識せずに一気に送ることができます。
めちゃくちゃ便利ですね。
今から使うんだったら全部FCMにまとめちゃった方が絶対に便利。
ここまで聞いてて、プッシュ通知を使うんだったらもう今だったらFirebaseを使えというようなことしか思い浮かばないんですけど。
通知基盤への依存と到達確認の難しさ
なんでガオルンがアーカイブされたかっていうところにつながるんですけど、
ガオルンが作られた当時はFCMこんな便利じゃなかった。
そもそもFCMなかったしGCMだったし、そんな便利じゃなかったし、APNSに対しても真面目にやる必要があった。
けど今からやるんだったらもう全部FirebaseのFCMに全部丸投げしてトピックもうまく使うことで、
大量にリクエスト送らなくてもうまく動くようにとか設計するってやればすごく便利だと思います。今からやるなら。
ファイアベース必須ですね。iOSに関してもプッシュ通知使いたかった。
アンドロイドはもうファイアベースで以外送る方法ないんですけど、APNSに関してもやっぱりAPNSを真面目に扱うのは最初説明した通りかなりめんどくさい。
多分ほとんどの人が触ったことないようなコードいろいろ書かないといけないので多分ほとんどの人できないと思います。
なのでそういうことをやらないといけないんでAPNSは。なので全部FCMに丸投げした方が平和。
ただFCMに丸投げする場合は中国のことどうするかっていうのは考えないといけない。
そこはビジネス上の判断。
ビジネス上?無視していいんだったら全部FCMにするし、無視しちゃいけないんだったら今後どうなるかわかんないけどAPNSのトークンをサーバー上でFCMに変換して送る。
もしその仕組みが使えなくなりましたってなったらもうAPNS真面目にやるしかない。
ってなると自分が最初の方に話したIPアドレスがいるよねとかその辺を全部真面目に考える必要が出てくると。
めんどくさいですね。
使えるだったらつめたいですね。
だからこれが考えるの大変だからガオルンができたんですよね。
PHPのアプリケーションからこんなの考えられないしそもそも実装もできないPHPだと。
だから丸投げできる機構っていうのが欲しくてガオルンができたんですよそもそも。
考え方的に今のファイアベースと若干近しいですねそのプッシュ通知の部分においては役目というか。
今となってもFCMがガオルンのSaaS版みたいになったんですよ。
だから今からだったら基本FCMに全部丸投げした方がいいしあとジョブ級の仕組みとかでFCMに対してリクエスト送るみたいな仕組み作れば
普通のアプリケーションでもある程度実装できるだろうしそっちの方が良いはず基本的には。
これちょっと聞いててやっぱ思ったのが中国からのアクセスももちろん考えないといけないんですけど
そもそもこのファイアベースにベンダーログインしてしまうじゃないですかプッシュ通知に関して
それを懸念してやっぱりガオルンみたいなプッシュ通知のファイアベースがやってくれてるようなプッシュ通知の処理をOSSで欲しいですよね現時点においても。
そうですねまあ今だったらFCMに全部丸投げするのがいいと思いつつ例えばそのプッシュ通知自体でビジネスやってますみたいな会社だと
全部FCMに丸投げたとちょっとビジネス上リスクがあると思いますねだからそうなるとガオルンみたいにAPNs真面目に扱うツールを自分で作るとか
あとOSSも確かいくつかあった気がするのでそういうツール使うとかそういう必要はあるかなと思いますね。
ですよねなんかちょっとかなりプッシュ通知みたいな重要なところをファイアベースにすべて握られてしまうというのもちょっと気持ち悪い話なんでね
ちょっと考えようによってはファイアベース使うしファイアベース使わないしみたいなところが必要そうですねここに関して
ただAndroidに関してはファイアベース以外の方法はないそもそもだからAndroidは考える必要ないですね
IOSに対してもファイアベースに全部まとめるかどうかっていうのはまあそうですね
結構Googleって結構互換性壊すというか古いやつどんどん切っていくじゃないですか
で実際ファイアベースも古いやつなくなったしなんで結構ねGoogleはある日突然古いやつ切り回すとか言うんで
APNSも全然ファイアベースにしてあー楽だわーとか言ってたらある日突然使えなくなりますとか言われる可能性はある
まあありますよねはしご外されることありますよね絶対に
そうですねなのでファイアベースIOSアプリ側にもファイアベース組み込んでれば基本的にそんなひどいことにならないと思うんですけど
やっぱりAPNSのトークンをサーバーサイド側で変換してるって場合は多分なくなると思いますそのうち
基本的にこれはファイアベースに移行するためのマイグレーションのために用意されてる仕組みなので
基本的にGoogle側はやめたいですよこれなので今だけかもしれませんっていう状況です
ずっと維持しててほしいですね頑張って
個人的にはこれずっと維持されるんであればもう全ファイアベースにした方がいいですよって自信持って言えるんですけど
なんかちょっとやめたそうな雰囲気がすごくあるのでだからちょっとAPNSにした方が安全かもしれませんみたいな
けどAPNS真面目にやるんだったら最初に言ったようなこと全部考えないといけませんっていう話をしないといけないですね
いろいろ考えるところはいっぱいありますねこのプッシュ通知周りは
そうですね真面目に会社に言うと思うんですけどねそのプッシュ通知自体のサーズとかもあるので
そういうサービスやってるとかだったらまた話が変わってくるし
実写サービスでプッシュ通知たくさん送ってますっていうんだったらFCMに全部まとめちゃうでもいいと思うし
この辺はねなんか堂々とらえるかだと思いますね
ビジネス上そのサービス上どこが重要かっていうところが重要そうですね
そうですね
何かが起きた時にぶっ壊さないようにするにはどうすればいいのかっていうのをちょっと考えないといけないですもんね運用上は
そうですねこの辺りどうするかですね今だったらファイアベースに全部まとめるのがベストプラクティスだと自分は思ってます
現時点において
現時点だとファイアベースに全部まとめるのであれば別に言語なんでもいいだろうしガオルンみたいな仕組みは多分なくても大丈夫
例えばAPNsを自分でやりたいってなったらやっぱりガオルンみたいな仕組みは必要になるよねっていうところですね
これ聞くだけでAPNsの辛みというか面倒くささみたいなところは分かってくれたかなと思うのでねこれ聞いてくれてる皆さんに関しては
なのでどこを頑張るかですね本当にもう
そうですねやっぱりみんな使うじゃないですかiOSアプリとかAndroidアプリスマートフォン持ってないって人いないから結局アプリやろうとしたらその辺の普通通知同寸の問題って絶対出てくるんですよ
なのでこの辺は知っておいて損はないんじゃないかなと思ってますね
ガオルン以外のOSSであるみたいな話途中で若干ありましたけど
そこら辺でこういうのが使われてるみたいなことあったりしますか知ってたりしますか
自分は実は今アプリやってないので今わからないしあとなんか正直真面目にメンテナンスしてるツールそんなないんじゃないかなと思ってますね
なのでこの辺は結構難しいですね
プッシュ通知周りはね結局その人たちが使ってればメンテナンスされてるけど使わなくなったらメンテナンスされなくなるって問題があるのでその辺が難しいですね
個人的にこのプッシュ通知周りの実装だったりとか仕事でも若干やってるんですけど
プッシュ通知難しいなと思うところがさっき途中でもあったんですけど過去のデバイストークンをずっと保持し続ける必要性があるって話あったじゃないですか
あれと全く一緒でクライアントに届いてみないとわからないじゃないですかプッシュ通知ってサーバー側から届いたかどうかってわかんないですよね
わかんないですねただAPNsとかFirebase側は知ってるはずなんですよそのコネクションがないから
けどそれはこっちからわかんないですね
ですよねウェブアプリケーション側からはこっちの開発者視点ではわかんないじゃないですか届いたかどうか
わかんないですね
そこが結構辛いなというかこれ送ったけど行ってんのかどうかみたいないうのって結構重要かなとは思うんですけど
まあそこら辺ももしかしたらあれですかねFirebaseとかのアナリティクスとかで見れるような機能とか
あんのかな自分見たことないですねFirebaseそんな機能あったかな最近あるかもしれないですねいやわかんないです
なんかいやそこら辺がすごい辛いなと思ってて普通にプッシュ通知見せてて
あのもうFirebaseとかこの辺はねもう信じるしかないですね
なるほどリクエストを送ってみてよし頼む送れてくれみたいなそんな感じなんですかね
そうですねこっちからするともうFCMとかAPNsに通信成功したらもうそれから先はもうわからんって感じですね
そういう類のもんだよねっていうことですねプッシュ通知は
そうですねプッシュ通知自体が障害になったらもうどうしようもないですね
なるほどプッシュ通知辛いよねっていうところから始まって
結局Firebaseが今だったら一番良さそうだよねっていうところで結構丸く収まったかなと思うんですけど
FCMはほんとすごいですよ
いやまあまあこんなところですかねガウルンはまあ今から作る意味はないんですけど
まあAPNs真面目にやろうとしたらこういうことやらないとダメです今でもこんなことやらないとダメですよっていうのは
まあまあみんなにしておいてほしいですかね
まあガウルンと似たようなことを頑張らないといけないって
いけないしまあまあGOが多分一番楽だと思いますやるとしたら
はいありがとうございますじゃあここまでにしようかなと思います
最後にあったりします
まあこういうねすでにアーカイブされてるけどその歴史的経緯
なんでこれそもそも作られたんだっけってところからじゃあ今からやるんだったらどうなるのってところまで話せることも
なんか話せるツールとかOSSがあったらまた話したいなと思うので
今後こういうことをやっていきたいですね
そうですねこのアーカイブされたものでもちゃんとこうアーカイブされててもパブリックですもんね
ガウルンに関してはまだコード見れますし
どういう経緯でこういった実装ができていってるのかなっていうのを見ること自体
まあかなり貴重なことかなと思うので
ぜひぜひ次とかも見ていけたらなと思います
はいということで今回ここまでにしたいなと思います
ヤウヨロズのOSSでは毎回一つのOSSを取り上げて
それについて片付いた変得の技術的なところも深掘りしながら話をしていく番組です
今後もその名の通りヤウヨロズのOSSを取り上げていけたらなと思ってますので
ぜひお聞きのプラットフォームで高評価やフォローの方お願いします
またこのOSSについても取り上げてほしいとかありましたらコメントとかXとかで教えていただけると非常に嬉しいです
自分のOSSとかでも全然構いませんのでよろしくお願いします
感想ももちろんお待ちしております
Xなどで呟く際にはハッシュタグヤウヨロズのOSSを付けてくださると見えつけやすくなるのでよろしくお願いします
それでは今回もありがとうございました
ありがとうございました