概要
タイトルの通りですがDevOpsDays Tokyo 2023に参加しました。
近々、GitLab、EKSを構築する予定があったのでこれらに関連したセッションを受け何か自身のプロダクト開発に活かせないか、という観点でセッションを選定しました。その中で感銘を受けたものについていくつか紹介いたします。
タイムテーブル
https://confengine.com/conferences/devopsdays-tokyo-2023/schedule/rich
カオナビのGitLab CI/CDにおける自動テスト運用と速度改善
4/18 14:00~ Hall C
GitLab及びSelf HostでのGitLab Runnnerを使用していく中で発生した課題、その対応策をご紹介いただきました。
状況
GItLab/GitLab Runner on EC2を使用しオートスケールせず台数固定で運用。
事象
- ジョブ実行時間の上昇 リソースの奪い合いが発生する
- 待ち時間の上昇 Workerに空きがない
- 失敗数の増加 OOM killer等
改善の前に
ジョブの実行について分析モニタリングできるようにする.
分析を以下5要素に分解して作業を進める。
- 仮説:解決したい問題を整理
- 計画:結論までの道筋を作る/どのようなデータを集めるのか決める
- データ:計画に沿ったデータの収集
- 分析:データの比較
- 結論:分析をまとめ結論を出す
この際の留意点としては
- データを集めすぎない
- まずはPDCAを回す
- 小さく始める
- とにかくアウトプットを出すことにこだわる
個人的に最初のデータを集めすぎない、というのが肝に感じました。分析する際は各種監視ツールにログを食わせるとしてもそれに応じたコストやその後の調査時間かかります。よりコスト最適な分析をするためどんなログを監視に回すかという判断基準は明確に持てるようにしていきたいです。
改善
改善案の提案にあたっては、現状、原因、打ち手、費用対効果の4点を軸に検討。
- 現状
- CI実行時間の上昇
- エラーの頻発
- 原因
- Jestがメモリ食っている
- 対応策
- ソフトウェアで解決
- Jestの設定変更
- ハードウェアで解決
- Jest専用のRunnerインスタンスを追加
- 既存のインスタンスを追加
- ソフトウェアで解決
- 費用対効果を鑑みた決定
- Jest専用のインスタンスを追加することで対応
話を聞いていてGitLab RunnerをAuto Acalingできれば解決するのでは?と感じていましたが今後の展望としてその施策を練っている段階のようでした。
個人的にはできるだけEC2の面倒を見たくないというのがあるのでGitLabをEKSクラスター内にホスティングすることも検討していきたいです。そもそものGitHubやGitLab.comをはじめとしたSaasとの比較も併せてやっていきたいです。
Building Apps in Kubernetes the DevOps way: Tools, Trick and Tips
k8sエコシステムの紹介
本セッションではk8sにマイクロサービスをデプロイするにあたり、その効率化を図るためのエコシステムが紹介されました。今回は特にセキュリティを担保するのに一役買うようなツールを以下紹介します。
通常セキュリティを高く保つということは開発スピードの低下に繋がる傾向にあります。紹介するツールを使用していくことで開発者体験を悪くすることなくセキュリティを向上させていきましょう、というのが主旨です。
- Secret management
- Container tools
- Container image signature
- SBOM(Software Bill of Materials)
- Valnerability scaninng
上記ツールを全て使用しなくてはならないということはないと思っていて(例えば、コンテナの暗号化はECRの暗号化設定で代用できそう)、そのシチュエーションに合わせたツールの選定基準というものを明確化していく必要があります。
特に興味を惹かれたのはSOPSを利用したConfigMapの暗号化です。
CLIによる情報の暗号化はAWS KMSを通じて暗号化することも可能で機密情報をGitで管理することも可能にすることができます。Commit Revision単位での細かいバージョン管理が可能になるのは秘匿情報の切り戻しが容易になることや、grepもできるようになるなど検索性も向上するのが大きなメリットであるように感じました。(個人のローカル端末にこっそり保管していました、みたいな事例も対応できるようになるかもしれません)
今回実演されたConfigMapだけでなくTerraformなどにも応用の効く話なのでこれは近い将来活用してみます。
最後に
後半の紹介したセッション冒頭であった、「開発者体験を下げることなくセキュリティを向上させる」ということについて、本カンファレンスではありませんがDockerCon(スライド63枚目)であった「Unusable security is not security.」という格言を座右の銘として生きていきます。
プロフィール
- アプリ開発の観点からインフラアーキテクチャに苦言を呈していたらいつの間にかインフラを触る人になっていました。