GitLabとKubernetesで作る、自動で起動・停止できるブランチ別環境 - JX通信社エンジニアブログ
SREのたっち(@TatchNicolas)です 本記事は、先日の弊社主催のTechトークイベントで発表した内容について、もうすこし詳細に書いてみます。 jxpress.connpass.com TL;DR; GitLabのenvironmentとHelmのreleaseを対応させることで動的な環境の作成・削除を実現した CIOpsとGitOpsを使い分けて、「ちょうどいい」使用感を目指した 環境の順番待ちがなくなった！ 背景 JX通信社のサーバサイド開発では、ECSによるコンテナベースでの開発・デプロイが主流です。*1 環境としては ローカル環境: docker-composeやgo run yarn run などで起動する、文字通り手元のマシンのローカル上で動かす環境 開発版環境: SQSやFirestoreなどのマネージドサービスや、ローカルで立てるのが大変な別のAPI*2との繋ぎ込
HDD・SATA SSD・NVMe SSD・Optane SSDで「レイテンシ」にどれほど差があるのか？
コンピューターのメインバスなどに直接接続される主記憶装置はレイテンシやスループットに優れていますが、その反面として小容量という問題を抱えています。容量問題を主眼に据える場合はHDDやSSDなどの補助記憶装置を用いるべきですが、その際に重要となる「レイテンシの差」について、エンジニアのルスラン・サフチェンコ氏がHDD・SATA SSD・NVMe SSD・Optane SSDにおける調査結果を解説しています。 A journey to io_uring, AIO and modern storage devices https://clickhoμse.tech/blog/en/2021/reading-from-external-memory/ 補助記憶装置はホスト側とデータのやりとりを行う際、1バイトごとではなくデータをひとまとめにした「ブロック」と呼ばれる単位で入出力を行っています。どの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
