📌

Sandbox環境を構築する上での設計思想

Ryusuke Shibuya

2023/11/06に公開

はじめに

社内でSandbox環境を構築しようという動きがあり、その際に重要視したいことなどを個人的に考えていたのでまとめておこうと思います。
実際に構築して運用した後に、体感したものなどは別で記事にしたいなと考えています。
ただし、一般的な本番環境をコピーするという意味でのSandbox環境ではなく、社内用システムをSandbox（開発者の遊びとしての場）として構築するといった意味合いになります。
Production環境そのものをSandboxとして扱うことに対してどのようなものが獲得できると考えるか、などなど
少しでも参考になるものがあれば幸いです。

※記載していく中でややこしくなったので、以降文言を統一しておきます。
Sandboxシステム＝Production環境そのものをSandboxとして扱ったシステム。
Sandbox環境＝一般的な意味合い。Production環境のコピーをして構築する遊び場。

ちなみに今回の機会でSandbox環境を構築する上での留意点や設計思想など調べてみてはいましたが、あまり体系的にまとまってるものは無い気がしますネ

一般的なSandbox環境における留意点

今回は少し特殊なのでそのまま全て気にする必要はないかと思いますが、基本的には以下の項目に留意する必要があるかと思います。

分離性: Sandbox環境は本番環境とは完全に分離されている必要があります。これにより、本番環境への影響を最小限に抑えることができます。分離性を確保するためには、独立したネットワーク、サーバー、データベースなどを使用することが重要です。

テスト環境やステージング環境と同様ですが、クラウドだとアカウントレベルでの分離が基本的には一番強固なものなのかなと考えています。

Sandboxシステムに対してもステージング環境やテスト環境など構築していくことになるかと思いますので基本的な考え方は一緒です。
Sandboxシステムに対してSandbox環境は必要か？という観点も出てきますが、これは個人的にあったほうが良いと思います。
詳細は後述しますが、これはSandboxであることによって検証できるものに大きな違いがあるという結論からです。

再現性: Sandbox環境は本番環境とできるだけ同じ状態を再現する必要があります。これにより、開発やテストの結果が本番環境での動作を正確に反映することができます。再現性を確保するためには、本番環境と同じバージョンのソフトウェアや設定を使用することが重要です。

Sandboxシステムに関しては当てはまらないですね。
本来の意味のSandbox環境や、その他ステージング環境には言わずもがな該当すると思います。

柔軟性: Sandbox環境は開発やテストの目的に応じて柔軟に構築できる必要があります。開発者やテスターが必要なリソースや設定を自由に変更できるようにすることで、効率的な作業が可能となります。柔軟性を確保するためには、自動化やコンテナ技術の活用などが有効です。

こちらもSandboxシステムに関してはそこまで重要でないように感じます。
どちらかというと、勝手に変更しないで、という形になると思うので。。。

セキュリティ: Sandbox環境は機密情報や個人情報などのセンシティブなデータを含まないようにする必要があります。また、セキュリティの脆弱性を最小限に抑えるために、適切なアクセス制御や監視機能を備えることが重要です。

機密情報や個人情報のマスキングという話に関しては、こちらもSandboxシステムに関しては当てはまりません。
ただし適切なアクセス制御やデータの暗号化、（運用における）セキュリティパッチの適用などは必要になってくるため、意識しなければいけない部分はあります。

リセット可能性: Sandbox環境は簡単にリセットできるようにすることが望ましいです。開発やテストのたびに環境を初期状態に戻すことで、再現性や柔軟性を高めることができます。リセット可能性を確保するためには、仮想化技術やコンテナ技術を使用することが有効です。

こちらもSandboxシステムである場合、当てはまりません。
万が一の障害やデータの損失が発生した場合に備えて、データのバックアップとリカバリは必要です。

やはりSandboxシステムとSandbox環境では、留意点は全く異なりますね。
考えてみると当たり前ですが、Production環境だからこその留意点の方がマッチすると思います。

Sandboxシステムで遊具となり得るもの

こうやって見ていくと、やはり社内の開発者向けといえど要件があり、様々な制約のあるSandboxシステムを開発者の遊び場と扱うのは難しいのかもしれません。
イメージしていたのは技術的にトレンドのものだったり、興味関心のあるものを採用して、システムを構築してみるという遊び場です。
ユーザー向けに公開しているものですと、技術選定に強い制約を伴います。

そんな中、技術や仕組みの運用に関してはProductionの運用・保守をしていく中で遊び場として検証していけるのではないかと思いました。
いくつか例を挙げてみます。

例１：開発ルール（制約）の変更

イメージし易かったのがESLintなど、開発における静的解析などの制約を変更するケースです。
理想を言えばこのルールで運用していきたいが、制約を厳しくし過ぎると開発者全体にルールが適用され一時的に生産性が低下すると見込まれると思われるもの。中長期的には品質面の向上や慣れ（スキル向上）により、生産性以上のものを獲得できるが、ビジネス計画とのバランスで直近GOと安易に判断できないことも多々あるのかなと思います。
ユーザー公開しているProductionとは別に切り離されたSandboxシステムでの運用をしてみることで、一時的なコストに関してもより精度高く見積もることもできますし、運用をしている中で妥当なラインでの設定値も体感値を持って測定していけるのではないか？と考えました。

一般的なSandbox環境では、個人の世界に閉じられてしまう。かといって開発チーム全体に適用するにはちょっと見切り発車である...
といった場合に関与者が限定され、ビジネス要件とは遠い世界で構築されているSandboxシステムがあれば気軽に仮説検証を繰り返せるのではないでしょうか？

例2：開発プロセスの変更

社内でGit-flowを採用しているが、何らかの問題があり、解決のためにトランクベース開発に移行したい！となった場合など。
関与者全員がトランクベース開発の経験があり、変更さえしてしまえば勝手に運用できる、といった状態であれば問題ないかと思いますが、学習を要するメンバーが大半だった場合は、気軽な気持ちで手を動かしながら経験・学習のできる環境になります。
こういった開発プロセスに変更を要するものは、ビジネス要求の強いProduction環境では他者に影響を与えることでボトルネックとなりえてしまうので実際やってみて学習しながら進めてみよう！は少し難しさを感じます。

例3：アーティファクトなど管理方式の変更

今回、ドキュメントの管理方式も検証する形で新しい取り組みをしようと考えています。
検討している変更点に関しては以下の通りです。

管理ツール、ドライブの変更
バージョン管理をシステムと合わせるため、開発プロセスの変更
フォーマットでの運用ではなく、テクニカルライティングを重視したスキル中心でのドキュメント作成

開発プロセスに手が入ったり、フォーマットがなくなったりと、いきなり本Productに反映させるには少しドラスティックな変更になっています。
ここら辺の検証が気軽にできるというのは、Sandboxシステムだからこそと感じます。
また、スキル的な話でいうと、どこまで獲得できれば本運用できるのか、という育成面の話が出てきますが、そちらは別枠で後述しています。

育成としての場

組織として学習を必要とするような新たな取り組みに関して、どのように学習を促し、どれほどの結果を満たせば導入OKとなるのか、測定や判断に迷うことは多々あります。
導入・運用ができると判断するための学習を促す方法として良くあるパターンはどのようなものでしょう？外部の研修コンテンツを利用する、だったりハンズオンやワークショップなど、実体験型のセミナーを自社で用意するでしょうか？
体系的に学習をすることも、手を動かし、体験をしながら学んでいくこともそれぞれ重要であると思いますが、それのみでコストがかかってくるとなると腰は重くなります。自社で育成コンテンツを用意するのは特に設計からかなりの時間を要しますし、なかなか手を付けられない印象です。特に単体の技術ではなく、運用を伴うものであればそれは明らかです。
ただし、それらのためのシステム環境という設計思想で構築していれば、運用ありき（正しく道具を使うため）の育成環境としても利用できるのではと感じます。その利用のためには制約を設けないという共通認識が重要になってきます。

測定・評価に関してはもっと難しいなと感じます。
結局、体系的に技術や運用手法（ベストプラクティスなど）を学んだとしても、実際にやってみて問題が発生することは多々あります。
書籍など座学からインプットしたことに対して、ちゃんと血を通わせて（正しい解釈をした上で）アウトプットする必要があり、この血を通わせるために必要なこと、というか近道が「実際にやってみること」と感じます。
そもそも今、利用している技術や運用している道具に関してはなぜ正しく利用できていると判断できるのでしょうか？
技術や道具を利用することで享受できるメリットを数値として測定できれば、それは大体正しく利用できている気もします。ただ、全てが数値化できるかというとそういう訳でもありません。
この測定・評価に関しては、メリットを享受できていると体感値でも感じられること、というのがとても大切になってくると考えています。
体感を得るためには手を動かして体験してみるしかありません。そしてこの定性的な評価は、数値で表現出来ない分見積もることが難しいです。だからこそ、育成としての場としてSandboxであるProduction環境は大いに意味を持つのではないかと考えています。
開発者体験としても関わる部分は大いにありますね。Sandboxシステム・環境が開発者体験へ与える影響などでも1記事書いてみたかったり。

SandboxシステムのSandbox環境は必要か？

これはもう、いよいよややこしいですね・・・汗
改めてですが、SandboxシステムはProduction環境のことを指しており、それに対するSandbox環境の必要性に関して記載していきます。
上記の通り、Sandboxシステムは何の遊び場足り得るかというと、運用や仕組みにフォーカスされると予想しています。
対して、Sandbox環境は単独での技術の遊び場になります。（運用等は二の次）

遊ぶ（検証する）対象が異なってくるため、システムそのものがSandboxだからという理由でSandbox環境が不要になるというのは違ってくるのかなというイメージです。遊ぶためには遊ぶ場所を選んで適切な遊び方を、ということですね！

Sandboxと開発者体験

Sandboxが存在することは開発者体験に大いに関わると個人的には考えているのですが、数ある定義の中でもこの観点に触れているものは少ないように思います。DX Criteriaが少しずつ掠っているかなという印象。特に「Sandbox環境」としては検証の文脈でちらほら見受けられます。
ただし、技術的な検証と研鑽という意味では取り上げられてないかなと感じます。

https://dxcriteria.cto-a.org/