さくらのクラウド開発の裏側

さくらのクラウドを開発しているエンジニア個人から見た開発の裏側を紹介します。

Transcript

1. © SAKURA internet Inc. さくらのクラウド開発の裏側 さくらインターネット株式会社 池添 正隆 2025年05月14日
2. © SAKURA internet Inc. 自己紹介 クラウド事業本部 クラウドサービス部 サービス開発 アプリケーションエンジニア （主にバックエンド） さくらのクラウドの認証認可・統制基盤 の開発担当 2006年～ さくらインターネットに入社 データセンター勤務開始 2009年～ さくらの専用サーバのサービス開発に従事 主にインフラ・ミドルウェアを扱う 2015年～ さくらの専用サーバ・VPSのバックエンド開発に従事 このころからアプリケーション開発を行う 2020年～ 衛星データプラットフォームTellusのバックエンド開発に従事 2023年～ さくらのクラウドバックエンド開発に従事
3. © SAKURA internet Inc. お伝えしたいこと • さくらのクラウドの直近の取り組み • アプリケーションエンジニアを取り巻く体制変化 • アプリケーションエンジニアがどういうことを考えて開発を行っているか
4. © SAKURA internet Inc. さくらインターネットの企業概要 インターネットインフラの提供を主力事業に、 東京/石狩/大阪にデータセンターを展開 国内のインターネットトラフィックを支えています 会社概要 本社所在地 ｜ 大阪府大阪市北区大深町 6 番 38 号グラングリーン大阪 北館 JAM BASE 3 階 創業年月日 ｜ 1996年12月23日（会社設立: 1999年8月17日） 上場年月日 ｜ 2005年10月12日（マザーズ） 2015年11月27日（東証一部（現プライム市場）へ市場変更） 資本金 ｜ 112億8316万円 従業員数 ｜ 連結927名 （2024年9月末） グループ会社 ｜ アイティーエム株式会社 / 株式会社S2i 櫻花移動電信有限公司 / ゲヒルン株式会社 ビットスター株式会社 / プラナスソリューションズ株式会社 IzumoBASE株式会社 / BBSakura Networks株式会社
5. © SAKURA internet Inc. さくらインターネットのサービス紹介 新サービス ＡＩ・人工知能 IoT 機械学習、データ解析、高精 度シミュレーション用途に特 化したGPUクラウドサービス さくらのセキュアモバイルコネクト クラウドにダイレクトに接続し、セキュ アでありつつ任意のネットワークへ接続 可能なSIMを提供する、IoT向けモバイ ルサービス 専用サーバ データセンター 高性能で拡張性と信頼性の高 いサーバをまるごと独占して 利用することができ、自由に カスタマイズして利用可能な サービス ハウジング データセンター内にお客様専 用のハウジングスペースを確 保し、ネットワーク機器や サーバなどの機材を自由に置 けるサービス レンタルサーバ 1台のサーバを複数の契 約者でサーバを共有また は占有することができ、 管理はさくらインター ネットに任せて使うサー ビス VPS・クラウド 仮想化技術を用い、1 台の物理サーバ上に複 数の仮想サーバを構築 し、仮想専用サーバと して分けた領域の占有 サービス 高性能サーバと拡張性の 高いネットワークを圧倒 的なコストパフォーマン スで利用できるIaaS型パ ブリック・クラウド・ サービス お客様の幅広いニーズに応えられるよう、クラウドコンピューティングサービスや IoTサービス、ハウジング、回線サービス等を提供してます。
6. © SAKURA internet Inc. さくらのクラウドのご紹介 【特徴】 1. 高い自由度と柔軟な構成で、多様なニーズに対応可能 2. 国内データセンター運用による高信頼性と高速通信 3. 明瞭な料金体系で、コストパフォーマンスに優れる
7. © SAKURA internet Inc. さくらのクラウド 直近の最重要項目
8. © SAKURA internet Inc. ガバメントクラウドへの取り組み
9. © SAKURA internet Inc. ガバメントクラウドについて デジタル庁が提供する政府共通のクラウドサービスの利用環境 参考URL: https://www.digital.go.jp/policies/gov_cloud
10. © SAKURA internet Inc. 環境払い出し 「政府情報システム等を運用するためのクラウド環境」 ▪デジタル庁がCSP（クラウドサービスプロバイダ）と契約 ▪クラウド利用料を支払い、利用システムに利用環境を払い出す ✓ インフラ構築管理コスト削減 ✓ インフラ構築管理工数削減 ✓セキュリティ品質向上 ✓開発スピード向上 ✓継続的改善の実現 CSP デジタル庁 契約・ 支払い 利用システム
11. © SAKURA internet Inc. クラウドサービスプロバイダについて コンピューティングリソース、ストレージ、アプリケーションなどのサービスを 提供する事業者になります。 例えば次のようなCSPがあります。 • Amazon Web Services • Google Cloud • Microsoft Azure • Oracle Cloud Infrastructure
12. © SAKURA internet Inc. ガバメントクラウドの認定CSPについて 2022年10月に認定されたCSP • Amazon Web Services • Google Cloud • Microsoft Azure • Oracle Cloud Infrastructure 2023年11月に条件付きでさくらのクラウドが認定されました。 条件とは2025年度までにすべての技術要件を満たすことです。
13. © SAKURA internet Inc. ガバメントクラウドの技術要件について 全305項目の技術要件があります。 2023年当時にさくらのクラウドが 満たしていた要件は約半数でした。 参考: https://www.digital.go.jp/procurement/3058bc41-ee8f- 49bb-8f22-8def725f6f3f 調達仕様書 別紙1（基本事項及びマネージドサービス の技術要件詳細）（Excel／73KB）
14. © SAKURA internet Inc. さくらのクラウドと技術要件 さくらのクラウドは2011年11月に開始されたサービスで 2023年時点では約13年たっていました。 13年間で約半数の技術要件を満たしている状態なのですが、 2年ちょっとで残り半数の技術要件を満たさないといけないことになります。 これだけ聞いてもハードルの高いことをやろうとしてるのがわかると思います。 社内でもこれまでのやり方では達成は困難という判断のもと新しいやり方を模索 していきました。
15. © SAKURA internet Inc. それまでのさくらのクラウドの開発体制 以前は大きな一つのチームで開発をしていました。当初は人数も少なく意思疎通 もしやすい状況でしたが、最終的には30人ほどの規模になり意思決定も難しく なってきている状態がありました。
16. © SAKURA internet Inc. 変更後のさくらのクラウドの開発体制 このため機能単位で5つのチームに分割し、それぞれが担当機能に責任を持ち開発 を進める体制に変更しました。
17. © SAKURA internet Inc. 開発体制変更にあたり大事にしたポイント 3つ観点を大事にして体制変更を行いました。 • 「ガバメントクラウドのための体制」ではなく「ガバメントクラウドを契機に 改善していく体制」 • 「中央集権型の体制」ではなく「小さなチームで大きな仕事」 • 「ひとりで、早く」ではなく「みんなで、遠くへ」
18. © SAKURA internet Inc. 開発体制変更後の変化 チームを分割することで各機能単位で意思決定を行えるようになりサービス開発 のスピードがあがりました。 また、チームごとに担当機能を設定することで以前よりも必要になるドメイン知 識の幅を抑えることができ、新しいエンジニアが開発に参加しやすくなりました。 実際、2025年2月には13サービスがリリースできました。 https://www.sakura.ad.jp/corporate/information/announcements/2025/03/12/1968218924/
19. © SAKURA internet Inc. クラウドAPI開発チームの担当機能 認証認可と統制基盤の開発を担当 • 認証認可 • 認証認可 • SSO連携 • 統制 • リソース管理 • 組織ポリシー • アクティビティログ管理 • セキュリティ脅威検知
20. © SAKURA internet Inc. まず初めにやったこと 当時の認証認可機能はIaaSの管理システムに乗っていました。 このシステムはサービス開発当初から動いているもので認証認可以外も含め当時 のさくらのクラウドの大部分の機能が動いているシステムでした。 長く稼働しているシステムでレガシーな部分も多く、スピード感をもって新規開 発を行うにはコストが高く、このシステムを拡張していくにはつらいと感じてい ました。 このため、認証認可機能の切り出しを行うことにしました。
21. © SAKURA internet Inc. システムの移行計画 移行するデータの把握 • データベースで移行するデータを確認 • 一つのテーブルの中で移行するカラム、残すカラムを精査 切り出しを行う機能・コードの把握 • 移行部分の確定 • どこは移行してどこは移行しないのか 移行前後で認証認可処理に差分が出ないように既存機能（API）のリストアップ • 機能数は900程度 • 移行前後でテストを行うことでデグレがないことを確認
22. © SAKURA internet Inc. Webアプリケーションフレームワークの選定 認証認可を別システムで切り出すことになったのでどのフレームワークを使うの か検討を行いました。 各言語で様々フレームワークが存在しています。 PHPならLaravel、Symfony、CodeIgniter PythonならDjango、flask RubyならRails などなど
23. © SAKURA internet Inc. 選定のポイント • 十分な機能はもっているか • ORMの機能は十分か • 利用できるライブラリは豊富か • フレームワーク自体の開発は活発か • 見つかった脆弱性はすぐに対応されるか • 公式ドキュメントが充実しているか • パフォーマンスに問題はないか • 何よりもスピード感をもって開発が進められるか
24. © SAKURA internet Inc. 選定の結果 Django自体の開発も活発で、必要な機能を実装するための周辺ライブラリDjango REST framework、django-otp、django-allauthなども充実していました。公式ドキュ メントも充実していてキャッチアップがやりやすい状況でした。 また、Djangoは2015年ごろからVPSや専用サーバのバックエンドとして利用実績が あり、コーディングガイドラインなどノウハウが溜まっていました。 機能的に十分で社内の実績ノウハウもあり、スピード感を持って開発ができると 判断しDjangoを利用することにしました。
25. © SAKURA internet Inc. システムの立ち上げスケジュール 概ね以下のようなスケジュールでリリースまで行えました。 • 2024年4月 チームメンバーのDjango学習期間 • 2024年5月 機能実装開始 • 2024年8月 テスト開始 • 2024年9月末 リリース 新システムのAPIエンドポイント数は40ほど、チームメンバーは当初5人で最終的 には9人になっていました。13年経ったシステムの認証認可というサービスの根幹 にかかわる機能を約半年で切り出すことができました。
26. © SAKURA internet Inc. Djangoを採用してみて 良かった点 • 開発が活発で周辺ライブラリも充実している • 社内で実績・ノウハウがありチーム開発が素早く立ち上げられた 課題になりそうな点 • 一サービスの実装を前提にしている • たとえばSAML連携を実装する際は一つの外部IdPと連携するような設計になっている、 さくらのクラウドでは複数のIdPと連携する必要がある • パフォーマンス • 現時点では問題になっていないが今後リクエスト数が増えた場合に高負荷部分の切り出し も必要になってくる
27. © SAKURA internet Inc. チームのコーディングガイドラインの紹介 コーディングガイドラインでは次の観点を定義しています。 • マインドセット • コーディングスタイル • コード実装 • DB設計 • URL設計 • ログ設計 • ユニットテスト実装 • コードレビュー
28. © SAKURA internet Inc. マインドセット メンバー間 • Team Geekで語られているHRTを実践する 開発 • SOLIDの原則 • YAGNI • KISS • ボーイスカウトルール
29. © SAKURA internet Inc. コーディングスタイル PEP8に準拠すると定めてます。 とはいえPEP8で語られていないものも存在します。 • 1行の最大文字数を超える場合の改行位置 • if文の書き方 … レビューで実装に集中できるようにruffで自動フォーマットをかけることで解決し ています。 中には守っていないものもあります。 • 1行の最大文字数（119文字に設定）
30. © SAKURA internet Inc. コード実装 Django、DRFでの実装について次の定義を行っています。 • モデル、シリアライザ、フォーム、テンプレート、ビューの役割 • モデル、シリアライザ、フォーム、テンプレートはできるだけ薄くする • ビューで機能を集約する • 必要に応じてビジネスロジックは個別クラスに切り出す • importの制約 • アプリケーションで相互importを避けるためにimportを一方通行に設定 • アプリケーションAはBからimportできるが逆はできない
31. © SAKURA internet Inc. DB設計 • 物理削除と論理削除の扱い • 基本的に論理削除を行わない（不要なデータはレガシーになってしまう） • 物理削除できないものは状態管理を行う • 注文情報なら申込、キャンセル、完了など • 扱うエンティティごとに正しく状態を整理して管理する • 作成、更新日時カラムの扱い • created_at、updated_atカラムはレコードの作成、更新日時を記録するだけでビジネス ロジック的な意味を持たせない • 例えば注文データを管理するテーブルで注文日時を扱いたい場合はordered_atのようなカ ラムを追加する • created_at、updated_atカラムでは意味が消失してしまう、場合によっては複数の意味 を持たせてしまうことを避けるため
32. © SAKURA internet Inc. URL設計 • 基本的にRESTfulなAPIに準拠する • リソース集合を扱う場合のURLは複数形で表現する • リソースのプロパティを表すURLは単数形を利用する • たとえばユーザーのプロフィール情報 /users/:id/profile • 動作を表すURLは適切なURLパスを設定する • たとえばサーバの電源ON /servers/:id/power-on
33. © SAKURA internet Inc. ログ設計 • ログレベルの設定 • ERRORレベル以上はアラートをあげる • loggingモジュールの出力にはプレースフォルダを利用する • ログを整理しやすいよう • 日本語でログ出力 • チーム状況的に母国語を日本語とするメンバーが大多数のため
34. © SAKURA internet Inc. ユニットテスト実装 ユニットテストでは次の観点を定義しています。 • 読みやすいテストを書く • 暗黙的な仕組みを導入しない • DRYよりも読みやすさを重視し、内容の重複や冗長な実装を許容する • テスト対象のパターンを網羅する • 正常系、異常系、境界値 • 値の比較 • 実装と同じロジックで値を比較しない • カバレッジ • カバレッジは目安 • ロジック部分の網羅性を重視する
35. © SAKURA internet Inc. コードレビュー コーディングガイドラインでは次の観点を定義しています。 • レビューの原則 • レビュアー、レビューイの共同作業であることを意識してお互いを尊重する • レビューはコードを改善するためのプロセス • レビューイの心構え • 大きなPRを作らない • 大きくなりそうなら意味のある単位で適宜分割してPRを出す • レビュアーの心構え • レビューを放置しない。すぐ着手できない場合はいつごろ着手できそうかコメントする • コメントは具体的な内容で行う
36. © SAKURA internet Inc. まとめ • さくらのクラウドのガバメントクラウドへの取り組み • ガバメントクラウドについて • ガバメントクラウドとさくらのクラウド • ガバメントクラウドを契機に起こった開発体制の変更 • 自チームで担当している認証認可・統制基盤のシステム開発の裏側 • 採用したフレームワーク • コーディングガイドライン
37. © SAKURA internet Inc. エンジニア募集 よりよいサービス、モダンなクラウドサービスにしていくためエンジニア募集中 です。ご興味を持たれた方はぜひご応募ください！ 認証認可/監査ログ基盤の募集 https://findy-code.io/companies/11/jobs/IOxa68timqf3k さくらインターネットの募集職種 https://findy-code.io/companies/11/jobs
38. © SAKURA internet Inc. ご清聴ありがとうございました。