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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© SAKURA internet Inc. 自己紹介クラウド事業本部クラウドサービス部サービス開発アプリケーションエンジニア（主にバックエンド）さくらのクラウドの認証認可・統制基盤の開発担当 2006年～さくらインターネットに入社データセンター勤務開始 2009年～さくらの専用サーバのサービス開発に従事主にインフラ・ミドルウェアを扱う 2015年～さくらの専用サーバ・VPSのバックエンド開発に従事このころからアプリケーション開発を行う 2020年～衛星データプラットフォームTellusのバックエンド開発に従事 2023年～さくらのクラウドバックエンド開発に従事

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 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株式会社

Slide 5

Slide 5 text

© SAKURA internet Inc. さくらインターネットのサービス紹介新サービスＡＩ・人工知能 IoT 機械学習、データ解析、高精度シミュレーション用途に特化したGPUクラウドサービスさくらのセキュアモバイルコネクトクラウドにダイレクトに接続し、セキュアでありつつ任意のネットワークへ接続可能なSIMを提供する、IoT向けモバイルサービス専用サーバデータセンター高性能で拡張性と信頼性の高いサーバをまるごと独占して利用することができ、自由にカスタマイズして利用可能なサービスハウジングデータセンター内にお客様専用のハウジングスペースを確保し、ネットワーク機器やサーバなどの機材を自由に置けるサービスレンタルサーバ 1台のサーバを複数の契約者でサーバを共有または占有することができ、管理はさくらインターネットに任せて使うサービス VPS・クラウド仮想化技術を用い、1 台の物理サーバ上に複数の仮想サーバを構築し、仮想専用サーバとして分けた領域の占有サービス高性能サーバと拡張性の高いネットワークを圧倒的なコストパフォーマンスで利用できるIaaS型パブリック・クラウド・サービスお客様の幅広いニーズに応えられるよう、クラウドコンピューティングサービスや IoTサービス、ハウジング、回線サービス等を提供してます。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© SAKURA internet Inc. ガバメントクラウドの認定CSPについて 2022年10月に認定されたCSP • Amazon Web Services • Google Cloud • Microsoft Azure • Oracle Cloud Infrastructure 2023年11月に条件付きでさくらのクラウドが認定されました。条件とは2025年度までにすべての技術要件を満たすことです。

Slide 13

Slide 13 text

© SAKURA internet Inc. ガバメントクラウドの技術要件について全305項目の技術要件があります。 2023年当時にさくらのクラウドが満たしていた要件は約半数でした。参考: https://www.digital.go.jp/procurement/3058bc41-ee8f- 49bb-8f22-8def725f6f3f 調達仕様書別紙1（基本事項及びマネージドサービスの技術要件詳細）（Excel／73KB）

Slide 14

Slide 14 text

© SAKURA internet Inc. さくらのクラウドと技術要件さくらのクラウドは2011年11月に開始されたサービスで 2023年時点では約13年たっていました。 13年間で約半数の技術要件を満たしている状態なのですが、 2年ちょっとで残り半数の技術要件を満たさないといけないことになります。これだけ聞いてもハードルの高いことをやろうとしてるのがわかると思います。社内でもこれまでのやり方では達成は困難という判断のもと新しいやり方を模索していきました。

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© SAKURA internet Inc. 開発体制変更後の変化チームを分割することで各機能単位で意思決定を行えるようになりサービス開発のスピードがあがりました。また、チームごとに担当機能を設定することで以前よりも必要になるドメイン知識の幅を抑えることができ、新しいエンジニアが開発に参加しやすくなりました。実際、2025年2月には13サービスがリリースできました。 https://www.sakura.ad.jp/corporate/information/announcements/2025/03/12/1968218924/

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© SAKURA internet Inc. まず初めにやったこと当時の認証認可機能はIaaSの管理システムに乗っていました。このシステムはサービス開発当初から動いているもので認証認可以外も含め当時のさくらのクラウドの大部分の機能が動いているシステムでした。長く稼働しているシステムでレガシーな部分も多く、スピード感をもって新規開発を行うにはコストが高く、このシステムを拡張していくにはつらいと感じていました。このため、認証認可機能の切り出しを行うことにしました。

Slide 21

Slide 21 text

© SAKURA internet Inc. システムの移行計画移行するデータの把握 • データベースで移行するデータを確認 • 一つのテーブルの中で移行するカラム、残すカラムを精査切り出しを行う機能・コードの把握 • 移行部分の確定 • どこは移行してどこは移行しないのか移行前後で認証認可処理に差分が出ないように既存機能（API）のリストアップ • 機能数は900程度 • 移行前後でテストを行うことでデグレがないことを確認

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© SAKURA internet Inc. 選定の結果 Django自体の開発も活発で、必要な機能を実装するための周辺ライブラリDjango REST framework、django-otp、django-allauthなども充実していました。公式ドキュメントも充実していてキャッチアップがやりやすい状況でした。また、Djangoは2015年ごろからVPSや専用サーバのバックエンドとして利用実績があり、コーディングガイドラインなどノウハウが溜まっていました。機能的に十分で社内の実績ノウハウもあり、スピード感を持って開発ができると判断しDjangoを利用することにしました。

Slide 25

Slide 25 text

© SAKURA internet Inc. システムの立ち上げスケジュール概ね以下のようなスケジュールでリリースまで行えました。 • 2024年4月チームメンバーのDjango学習期間 • 2024年5月機能実装開始 • 2024年8月テスト開始 • 2024年9月末リリース新システムのAPIエンドポイント数は40ほど、チームメンバーは当初5人で最終的には9人になっていました。13年経ったシステムの認証認可というサービスの根幹にかかわる機能を約半年で切り出すことができました。

Slide 26

Slide 26 text

© SAKURA internet Inc. Djangoを採用してみて良かった点 • 開発が活発で周辺ライブラリも充実している • 社内で実績・ノウハウがありチーム開発が素早く立ち上げられた課題になりそうな点 • 一サービスの実装を前提にしている • たとえばSAML連携を実装する際は一つの外部IdPと連携するような設計になっている、さくらのクラウドでは複数のIdPと連携する必要がある • パフォーマンス • 現時点では問題になっていないが今後リクエスト数が増えた場合に高負荷部分の切り出しも必要になってくる

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© SAKURA internet Inc. コード実装 Django、DRFでの実装について次の定義を行っています。 • モデル、シリアライザ、フォーム、テンプレート、ビューの役割 • モデル、シリアライザ、フォーム、テンプレートはできるだけ薄くする • ビューで機能を集約する • 必要に応じてビジネスロジックは個別クラスに切り出す • importの制約 • アプリケーションで相互importを避けるためにimportを一方通行に設定 • アプリケーションAはBからimportできるが逆はできない

Slide 31

Slide 31 text

© SAKURA internet Inc. DB設計 • 物理削除と論理削除の扱い • 基本的に論理削除を行わない（不要なデータはレガシーになってしまう） • 物理削除できないものは状態管理を行う • 注文情報なら申込、キャンセル、完了など • 扱うエンティティごとに正しく状態を整理して管理する • 作成、更新日時カラムの扱い • created_at、updated_atカラムはレコードの作成、更新日時を記録するだけでビジネスロジック的な意味を持たせない • 例えば注文データを管理するテーブルで注文日時を扱いたい場合はordered_atのようなカラムを追加する • created_at、updated_atカラムでは意味が消失してしまう、場合によっては複数の意味を持たせてしまうことを避けるため

Slide 32

Slide 32 text

© SAKURA internet Inc. URL設計 • 基本的にRESTfulなAPIに準拠する • リソース集合を扱う場合のURLは複数形で表現する • リソースのプロパティを表すURLは単数形を利用する • たとえばユーザーのプロフィール情報 /users/:id/profile • 動作を表すURLは適切なURLパスを設定する • たとえばサーバの電源ON /servers/:id/power-on

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© SAKURA internet Inc. ユニットテスト実装ユニットテストでは次の観点を定義しています。 • 読みやすいテストを書く • 暗黙的な仕組みを導入しない • DRYよりも読みやすさを重視し、内容の重複や冗長な実装を許容する • テスト対象のパターンを網羅する • 正常系、異常系、境界値 • 値の比較 • 実装と同じロジックで値を比較しない • カバレッジ • カバレッジは目安 • ロジック部分の網羅性を重視する

Slide 35

Slide 35 text

© SAKURA internet Inc. コードレビューコーディングガイドラインでは次の観点を定義しています。 • レビューの原則 • レビュアー、レビューイの共同作業であることを意識してお互いを尊重する • レビューはコードを改善するためのプロセス • レビューイの心構え • 大きなPRを作らない • 大きくなりそうなら意味のある単位で適宜分割してPRを出す • レビュアーの心構え • レビューを放置しない。すぐ着手できない場合はいつごろ着手できそうかコメントする • コメントは具体的な内容で行う

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© SAKURA internet Inc. エンジニア募集よりよいサービス、モダンなクラウドサービスにしていくためエンジニア募集中です。ご興味を持たれた方はぜひご応募ください！認証認可/監査ログ基盤の募集 https://findy-code.io/companies/11/jobs/IOxa68timqf3k さくらインターネットの募集職種 https://findy-code.io/companies/11/jobs

Slide 38

Slide 38 text