前置き
こんにちは、インフラ部のsue445です。
下記の記事でも書いたように、先日開催されたPIXIV DEV MEETUP 2024のキーノートでインターコネクト同時開設に関して話をしました。 inside.pixiv.blog
発表スライドだけでは当日喋った内容が伝わらないと思ったため、本記事では当日喋った内容の書き起こしを掲載したいと思います。
書き起こし全文
諸注意
場所によっては日本語が若干変な文章になっているかもしれませんが、その場の雰囲気を出すために言い間違え以外は実際に喋った内容をそのまま掲載しているのでご了承ください。（文章を直しすぎるとそれはもう書き起こしじゃなくなるので...）
P1
（場内拍手）
ご紹介にあずかりましたインフラ部の末吉です。
我々インフラ部では直接プロダクト開発に携わっているわけではないんですけども、間接的に創作活動を支えています。
P2
ピクシブではクリエイターの皆様を支えるためのサービスをこれだけリリースしています。
インフラ部ではpixiv.netを始めとするこれら全てのサービスのインフラを見ています。
P3
そして我々はエンジニアをはじめとする「創作活動を支える人たち」も支えています
P4
先程のエンドユーザー向けのサービスの他にも、GitLabやSentryやKubernetesなどの開発者向けのツールの運用もしています。
P5
ピクシブといえばこういうベニア板のサーバが有名でしょう。
長年社内のサーバーラックでこのベニヤサーバが開発環境として運用されてたんですけども、とうとう昨年全てデータセンター内のOpenStackに移行しました。
（場内から拍手喝采）
さっき出したKubernetesも一部このOpenStack上で動かしています。
P6
創作活動を支えるために、インフラ部では毎年様々な挑戦を行っています。
P7
私は昨年のPIXIV MEETUPで このような発表 を行っていました。
昨年Doingだったこの2つは現在両方とも本番稼働してます。
2つ目の既存サービスのKubernetes移行に関しては、今日のメインセッションで話されていたものになります。
このキーノートでは1個目の「オンプレミス環境と各クラウドとの閉域網接続」に関して、実際に本番稼働させるまでのチャレンジとプロセスについて少しだけ話そうと思います。
P8
今年ピクシブはPastelaとpixivcobanという2つのサービスをリリースしました。
PastelaではAWSのECSを、pixivcobanではGoogle CloudのCloud Runをそれぞれ利用しています。
P9
双方の開発の初期段階、ほぼ同時期にそれぞれある相談がきました。
P10
その相談というのは
- 新規のサービスをクラウドでリリースしたい
- オンプレ側にある認証基盤や決済基盤をクラウドからも利用したい
というものでした。
マジでシンクロニシティでしたｗ
P11
それぞれ僕はこのアーキテクチャの選定にも携わりました。
チームのスキルセットや作りたいサービスの特性なども考慮して各チームと相談した結果、PastelaではAWS、pixivcobanではGoogle Cloudを利用することになりました。
P12
例えばオンプレミスで動いてるアプリケーションからECSとかCloud Runにあるサブシステムを実行するなど、これまでもオンプレミスからクラウドへのインターネット経由での連携は行っていました。
P13
しかし今回はクラウドからオンプレミスへの閉域網接続が必要でした。
閉域網接続、インターコネクトというのはインターネットを通らない通信のことです。イメージ的には専用線に近いんですけどもちょっと違います。
このような閉域網接続は弊社ではほぼ初の試みでした。
リリースの予定時期もPastelaとcobanでほぼ同じくらいだったんで、結果AWSとGoogle Cloudで同時にインターコネクトを開設することになりました。
マジで狂気でしたｗ
（場内爆笑）
P14
構成技術としてはAWSはDirect Connect Gateway、Google CloudではCloud Interconnectをそれぞれ採用しました。
P15
インターコネクトの開設にあたって様々なチャレンジがありました。
今回はそのチャレンジに対するプロセスを1個だけ紹介したいと思います。
P16
それは「クラウドからオンプレミスへのDNSに対して通信を行う」ということです。
クラウドからオンプレへのDNSに対してインターコネクト経由で通信を行うだけでも様々な困難がありました。
P17
例えばクラウド上にあるアプリケーションからオンプレミス側にある foo.example.internal に通信する場合を考えます。
この時、こんな図のような構成になります。
まずクラウドの中から foo.example.internal のゾーンである example.internal への通信をクラウド内のDNS転送ゾーンに転送します。
AWSではRoute53 Resolver、Google CloudではCloud DNSの転送ゾーンにあたります。
この転送ゾーンがいったんクラウド内のDNSのクエリを受け付けて、インターコネクト経由でオンプレのネームサーバの方に転送します。 この転送ゾーンがオンプレ側とクラウド側とのDNSの二重管理を防いでいます。
オンプレ側のネームサーバは弊社ではBINDを使ってます。 BINDがインターコネクト経由でサービスのプライベートIPを返します。
返されたプライベートIPをもとに、アプリケーションがインターコネクト経由で実際のエンドポイントを叩いて、オンプレ側のアプリが決済基盤とかアカウント基盤とかのなんか、APIの実行結果 *1 をインターコネクト経由でレスポンスを返します。
手法は違うものの基本的にはAWSとGoogle Cloudでほぼ同じような構成をとりました。 しかし、Google Cloudの場合DNSサーバの仕様が一部AWSと異なるため特殊な対応を行いました。
P18
例えばAWSの場合、AWSのRoute53 resolverというのはVPCに紐づけられているんで、Route53がBINDに通信する場合の送信元のCIDRはVPCのCIDRになります。
この図でいうところの 10.xxx.xxx.xxx/27 がVPCのCIDRになります。
P19
しかしGoogle Cloudの場合、Cloud DNSはVPCの外で動いてるんで、BINDに通信する時の送信元のCIDRがCloud DNSのCIDRになります。
具体的にはここの 35.199.192.0/19 って書いているやつです。
P20
インターコネクトの回線が1個だけならこれでもよかったんですけども、今後2つ目以降のインターコネクトの機器を追加した時に困ることが予想されました。
戻り先はオンプレミス側で指定するんですけども、CIDRが同じだと当然戻り先は固定になります。
行きのルートはそれぞれのなんか回線 *2 なんですけども、戻りのルートがなんかその1個の回線に固定されてしまって、そこがSPOFになって困ることが予想されました。
P21
そのためどう解決したかっていうと、VPCの中にDNSのサーバを別に立てて、Google CloudからオンプレのDNSを参照する時はそこを経由させるようにしました。
具体的にはVPCの中にGKE Autopilotのクラスタを立てて、その中で動いているcorednsがクエリを受け付けています。
P22
実際にはこういうルーティングになりました。
P23
その他技術的な詳しいことは先日こっちのテックブログに書きました。
もしも興味ある方は御覧ください。あと懇親会で感想を聞かせてくれると嬉しいです。
P24
僕はインフラ部でたくさんの仕事をしています。そして、色んな顔を持っています。
そのうちの1個であるソリューションアーキテクトとしてこのような持論を持っています。
まずアーキテクチャに正解はないです。その時系列や組織構成によって最適解が変わります。
そしてその最適解を出すために我々は常に挑戦し続けています。
ご清聴ありがとうございました。
（場内拍手）
当日の反応
下記でまとめています。
懇親会で聞いたみんなの感想
- 事前のinsideがなかったら半分も理解できなかったw
- （Cloud DNSのCIDRの仕様に関して）「マジか？」って思って調べたらマジだった...
- 最近Cloud Interconnectを開設したのでCloud DNSの仕様に戸惑ったのがわかりみしかなかった。
余談
特に意識はしてなかったんですが、インターネット企業でみんなご存知インターネットの基礎に関してキーノートをできたのは我ながらいい選択だと思いました。
インターネット企業のピクシブではインターネットが好きな人をお待ちしています。
