NTTドコモ R&D Advent Calendar 2023の12月13日の記事です。
はじめに
NTTドコモ データプラットフォーム部（以下ドコモDP部）の伊藤です。
本記事は、「社員1000人以上が使う、Streamlit in Google Cloudのサーバレスプラットフォームを完全内製してみた」で言及しているプラットフォーム上で提供しているアプリ開発環境部分を取り上げて紹介させていただきます。
このプラットフォームはGoogleCloud上に構築されており、社員であればだれでも申請制でアプリ開発を始めることができるようにしています。
元々このアプリ開発環境としてGCEを利用してきましたが、よりセキュアでスケールできるCloud Workstationsに全面移行いたしましたので設計・運用時の工夫点について紹介させていただければと思います。
なお、検討・実装についてはNTTデータの支援メンバーである兼子さんに進めてもらっており、以降のセクションは兼子さんに執筆いただいております。
Cloud Workstationsとは
Cloud WorkstationsとはGoogleCloud上で利用できるマネージドでセキュアな開発環境を提供するサービスで、2023年4月に東京リージョンで利用できるようになりました。
今までの開発環境の構成と比較するとCloud Shellより自由に使えてGCEより管理のしやすいバランスの取れたサービスだと思います。
| Cloud Shell | Cloud Workstations | Compute Engine (+IAP) | |
|---|---|---|---|
| 環境の自由度 | ✖カスタマイズ不可（特にディスク要件が厳しい...） | 〇マシンリソースやNW、コンテナなどをカスタマイズ可能 | ◎他の構成より自由に設定可能 |
| 管理者視点での管理のしやすさ | ◎定期的に自動アップデートされるため管理がほぼ不要 | 〇configを修正することで一気に構成変更を適用できる | ✖脆弱性などの対応を個別に行う必要がある |
| 利用者視点での環境構築のしやすさ | △利用者自身で行う必要がある | 〇必要な資材をプリインストールできる | ✖IAP DesktopやSSHなどの接続設定が別途必要になる |
| コスト | ◎無料！！！ | △利用手数料が発生するのでほかの構成より割高 | 〇GCE（＋ディスク）の料金だけ |
設計・運用時に工夫したこと
1チーム1ワークステーションにする
下記の通りCloud Workstationsは基本的に開発者1人あたり1ワークステーションを割り当てる構成とするのが環境分離の観点から推奨されているサービスなのですが、次の理由から私たちのプラットフォームでは1チーム1ワークステーションとしました。
IAM 権限
デフォルトの Identity and Access Management 構成を使用して、ワークステーションへのアクセスを単一のデベロッパーに制限します。これにより、各デベロッパーが、基盤となる独立した VM を持つ一意のワークステーション インスタンスを使用するため、環境が分離されます。
引用元: https://cloud.google.com/workstations/docs/set-up-security-best-practices?hl=ja#iam-permissions
チーム単位にした理由
コスト
マシンタイプe2-standard-8/SSD100GBのワークステーションを1人1台に割り当てた場合、ワークステーション1台あたりの料金は約260ドル/月です。
仮に100人の開発者が利用した場合、ワークステーションの利用料金はおよそ$26,099.68/月となり、正直コストが高いと感じました。[1]ガバナンス面での不安
ワークステーション内での利用状況把握が難しく、アプリ開発という目的以外の利用のチェックなどガバナンスを利かせにくいと思いました。
ワークステーションを開発チーム単位で払い出すことができれば、ワークステーション内の利用状況管理を各チームのリーダに委譲できると考えました。運用負荷
開発者の追加・削除のたびにワークステーションの払い出し・削除作業を行うのは開発者が増加した場合、運用負荷が高いと判断しました。
ワークステーションはチーム単位で払い出し、開発者の追加作業は各チームのリーダに任せることで運用負荷の削減を行いました。
チーム単位で利用するための実装と気を付けたこと
Cloud Workstationsはデフォルトではアクセスした際に存在しているLinuxユーザーは1名分のみ("user"という名称のユーザー)しか存在しておらず、
チーム単位で利用しようと思うと、複数人のLinuxユーザーを起動シェルで作成する必要があります。
そのような起動シェルの組み込みのために、専用のカスタムコンテナイメージ[2]を作成して、それをもとにCloud Workstationsを起動させています。
ただし、この実装において作成するCloud WorkstationsのLinuxユーザーの情報をカスタムコンテナイメージ内のファイルによって管理してしまうと、チームごとに個別のカスタムコンテナイメージとCloud Wokrstations configを作成し、かつ、チームメンバーの増減のたびにカスタムコンテナイメージを再構築する必要があり、運⽤
負荷が⾼くなることが想定されました。
それを回避するための実装として、チームメンバーの情報を永続ディスクに保存し、チームメンバーの増減時にチームリーダーがメンバー情報を更新する運⽤とすることで、運⽤負荷の削減を図りました。
定刻シャットダウンを導入する
Cloud Workstationsではidle timeoutとrunnning timeoutという2つの設定値により、利用者が明示的にワークステーションを停止しなくてもよい仕組みがあります。
しかし、ワークステーションのコストや長時間労働につながる観点で問題がありました。
idle timeoutを短くしてしまうと、業務時間中に停止してしまう可能性が高くなり不便という意見が利用者からあり、
一方、runnning timeoutを短くしてしまうと、複数人で利用しているため何時に停止するかわからず、急に停止してしまうと作業内容を失ってしまう可能性がありました。
そこで私たちのチームでは定刻に停止する仕組みを導入しました。
これはCloud Workstations単体では設定できないため、Cloud Composerで定刻になったらすべてのワークステーションを停止するDAGを作成しました。
カスタムコンテナイメージを利用して開発環境の構築手順を簡単にする
アプリ開発に共通で必要なリソース(私たちの環境ではGitHubのCLIなど)を事前にカスタムコンテナイメージにインストールしておき、開発環境の利用開始時の手間を減らし、開発者がアプリ開発に集中できるようにしました。
また各利用者に個別で実行してほしい環境構築手順をシェルスクリプトにまとめ、簡単に導入できるようにしました。
具体的には以下のような処理をシェルスクリプトにまとめました。
poetryのインストールとパスの追加
echo export PATH=~/.local/bin:$PATH >> $HOME/.bashrc curl -sSL https://install.python-poetry.org | pythonIDEのポート番号とStreamlitのプレビュー用ポート番号を環境変数に登録
echo export PORT_IDE=XXXX >> $HOME/.bashrc echo export STREAMLIT_SERVER_PORT=XXXX >> $HOME/.bashrc- Streamlitのプレビュー用エイリアスの登録
alias streamlit_show_url="xdg-open http://localhost:$STREAMLIT_SERVER_PORT"
カスタムコンテナイメージを定期的にメンテナンスする
公式ドキュメントにもベストプラクティスとして書かれているようにカスタムコンテナイメージを利用する際は、コンテナの定期的なメンテナンスが推奨されています。
組織でカスタム イメージを使用している場合は、イメージを定期的に再ビルドしてください。次のセクションで説明するように、安全なイメージ パイプラインを作成することをおすすめします。
しかしベースとなる公式のCloud Workstations用イメージの仕様変更によってカスタムコンテナイメージが動作しなくなってしまうと、すべてのワークステーションに影響が発生するため、現状はイメージパイプラインを作成せず手動での定期的なチェックと再構築を行っています。
おわりに
Cloud Workstationsは今年GAされたばかりのサービスということもあり、未だ一般的な運用のベストプラクティスは明に確立されていないと認識しています。
本記事でご紹介させていただいたのはあくまで私たちのチームにおける運用方法ですが、上記の内容がCloud Workstationsの利用を検討、もしくは利用されている方のご参考になれば幸いです。
また今後の展望としては、Cloud Wokrstationsで利用するコンテナイメージを(現在は上述の通り定期的に手動で管理していますが、)自動で定期的に再構築し、カナリアリリースできるような仕組みの導入に向けた検討を行っております。
注釈
[1] ワークステーションのコストの試算
Cloud Workstationsのコストは次のようになっています。
ワークステーションの台数 × (VMの利用料金 + 永続ディスクの料金 + ワークステーション管理手数料) + コントロールプレーンのクラスタ料金
1ヶ月を22営業日とし、1日あたり10時間 (1日の営業時間8時間＋アイドルタイムアウト時間2時間)稼働した場合、この式の基づいて各種料金を集計すると次のようになります。
※ただし各種割引は考慮しないものとします
VMの利用料金: マシンタイプe2-standard-8を利用した場合 220時/月 × $0.4984 /時 = $109.648/月 永続ディスク利用料: SSD100GBを使用した場合 100GB × $0.104/月/1GB = $10.4/月 ワークステーション管理手数料: 220時間/月 × $0.64/時 = $140.8/月 1ワークステーションあたりの料金(コントロールプレーンのクラスタ料金を除く): $109.648/月 + $10.4/月 + $140.8/月 = $260.848/月 コントロールプレーンのクラスタ料金: これはworkstationの稼働状況に依存しないので、1ヶ月を31日として 24時/日 × 31日/月 × $0.20/時 = $14.88/月 ワークステーション100台の場合の1ヶ月の料金: 100 × $260.848/月 + $14.88/月 = $26,099.68/月
[2]コンテナをカスタマイズする
https://cloud.google.com/workstations/docs/customize-container-images?hl=ja
