【サイボウズインターンシップ2026】プラットフォーム（自社基盤）コース　紹介資料

インターン説明会 ~プラットフォーム（自社基盤）コース紹介 ~ サイボウズ株式会社 クラウド基盤本部 國領 正真 1

Kubernetes 環境に移行したサービスのアーキテクチャ改善 • 多くのサービスが Kubernetes を用いた新インフラ基盤 Neco へ移行した • 現在は移行時に解消しきれなかったいくつかの問題を解消するフェーズ • 旧基盤において課題となっていた点を技術的に解消する o クラウドネイティブでないミドルウェア群の刷新 o Fine grained なアクセス制御の実現 2

インターンシップで予定しているタスクの例 • 内製分散 KVS の負荷試験・性能改善 • 新しい認証システムを使ったサービス間認証の実装 • TiDB を使用した非同期処理システムの実行履歴の検索 • コードの静的解析と内部ルールの強制 • …… etc オフラインで開催予定！ （交通費・宿泊費 支給） 3

インターンに参加して得られるもの • Go や Rust を利用したソフトウェアの開発経験 • 分散システムの開発経験 • クラウド基盤開発・運用・移行のノウハウ（苦労話） 4

チーム紹介 プロダクト Neco 移行チームの開発体制 • 5人チーム • 基本的にオンラインで作業 • 私は基本的に東京オフィスに出社 • 他のメンバーも東京オフィスに所属しているが基本リモート • 四半期ごとくらいにオフラインで集まってミーティング • 一人でコーディング → コードレビュー • 書くコードの量は多め • アプリ開発チームとコミュニケーションを取りながら開発 5

チーム紹介 チームで開発しているコンポーネント • 非同期処理システム • 申し込み内容をもとにアプリケーションをセットアップ • サービスディスカバリ • お客様の情報と使っているサーバの紐付けを管理 • ロードバランサ • 新旧基盤にリクエストを振り分ける。 • API Gateway • AWS など一部外部サービスからクラスタ内の API を呼び出す • インメモリデータベース • ユーザのセッション管理などに利用 6

インメモリデータベース 旧基盤のインメモリKVS | Keepalivedによる冗長化 • Yrmcds という独自の仕様を持つ Memcached 互換 KVS をVMベースの旧基盤上で運用している • https://github.com/cybozu/yrmcds • Keepalived を使ってプライマリを選出、プライマリの持つ IP アドレスへレプリカがアクセスし、 データを非同期的にレプリケーション • リーダーの障害時には Keepalived によって IP アドレスが移動し、いずれかのレプリカが自動で昇格 Primary VM 1 VM 2 VM 3 yrmcds yrmcds yrmcds keepalived keepalived keepalived 7

• https://github.com/cybozu/yrmcds

インメモリデータベース Kubernetes 環境におけるインメモリ KVS • 月に1回クラスタの更新のため全 Pod が再起動し、単一 Pod のインメモリのデータは揮発する o レプリケーションしてデータを冗長化でき、自動でフェイルオーバーできる必要がある • Kubernetes の Lease などを利用したシンプルなリーダー選出だけでは不十分 o 例：レプリケーションが追いついていないレプリカにも昇格する可能性がある o より堅牢なレプリケーション・フェイルオーバー / スイッチオーバーの仕組みが必要 I’m primary! Pod 2 (Lost) Pod 1 KVS KVS dataRevision: 2 Pod 3 KVS DATA LOST… dataRevision: 3 Lease 8

インメモリデータベース Rust を用いた分散 KVS の実装 • 既存アプリが yrmcds の独自仕様に依存しており、OSS ではニーズを満たす物がなく、 自前での実装が必要になった • レプリケーションの仕組みは Kafka や Valkey を参考にして開発中 • 負荷検証や障害を再現したときの振る舞いなどの試験、改善に取り組みたいと考えている Replicate Pod 1 KVS Primary Monitor and select primary Pod 4 Leader Controller Lease Pod 2 Pod 5 KVS Controller Pod 3 KVS 9

サービス間認証 NetworkPolicy の限界 • Neco において簡単にサービス間のアクセスを制限するためには NetworkPolicy が利用可能である • しかし、NetworkPolicy ではアクセス先でアクセス元サービスを正しく識別することは困難である • なんらかの認証・認可の仕組みを用いるようにしたい • それを簡単に使えるようにしたい！ namespace1 Pod namespace2 Pod NetworkPolicy Allow from: namespace1 namespace2 Pod Who request this? 10

サービス間認証 SPIFFE（Secure Production Identity Framework For Everyone） • 2022年に CNCF Graduated に到達したプロジェクト。認証のための標準仕様である。 • SPIRE（SPIFFE Runtime Environment）がそのリファレンス実装として存在する。 • SVID（SPIFFE Verifiable Identity Document）を用いてサービスを認証する。 Request from app! Request with SVID X.509 SVID Pod Pod SPIFFE ID spiffe://example.com/ns/app Trust domain Path Issue SVID Verify SVID SPIRE 11

再掲：インターンシップで予定しているタスクの例 • 内製分散 KVS の負荷試験・性能改善 • 新しい認証システムを使ったサービス間認証の実装 • TiDB を使用した非同期処理システムの実行履歴の検索 • コードの静的解析と内部ルールの強制 • …… etc 12

最後に • 本番環境で実際に稼働するコンポーネントを対象とした実タスクを 経験できるインターンの予定です。 • オフラインでの開催を予定しています o サイボウズ東京オフィスにて2週間の開催予定 o 交通費・宿泊費支給 • チームの業務内容に興味のある方のご応募をお待ちしています。 • 応募には事前課題の提出が必須です。ご注意ください。 13

©️ Cybozu, Inc. 14