私のToDo Appには、Docker Composeを使ってフロントエンドとバックエンドの両方でnpm run testを実行するGitHub Actionsがあります。以前はイメージをビルドしてからテストを実行するのに4分48秒かかっていましたが、buildxキャッシュバックエンドを使うことで、2分18秒にまで短縮されました。レイテンシは2:30短縮され、パフォーマンスは2倍以上向上しました（関連するプルリクエスト）。この記事では、キャッシュの恩恵を受けるために追加できる簡単な手順を紹介します。

KubernetesのHPA(Horizontal Pod Autoscaling)を利用する場合、希望する数のPodがデプロイされるまで時間がかかることがあります（クラスタ・オートスケールのスケールアウト時など）。 それまではサービス品質が低下する可能性があり、例えばトラフィック量が急激に増加した場合、応答レイテンシが非常に大きくなる可能性があります。 本記事では、過去のデータなどからリクエスト量の推移を大まかに推測できることを前提に、予想されるトラフィック増加の前にKubernetesのCronJobを使ってHPAの最小レプリカ数を調整することで、サービス低下を緩和する方法を紹介します。 また、CronJobのテンプレートと、CSVファイルの値を使用してテンプレートからCronJobマニフェストを生成するPythonスクリプトを記述します。

以前の記事で、KubernetesのHorizontal Pod Autoscaler (HPA) のデモを行いました。 その記事ではCPU利用率を対象にオートスケーリングを設定していましたが、今回は当該Podのリクエスト処理時間をHPAのターゲットに設定します。 アプリケーション側でメトリクス値を管理するのは手間なので、リクエスト処理時間のメトリクスはサービスメッシュIstioから取得することにします。

サービスメッシュの代表格であるIstioをKubernetesクラスタに導入する機会がありました。 それまでは、Istioとは何か、なぜサービスメッシュが支持されているのか全く知らず、IstioはDevOpsロードマップで辛うじて名前を知っている程度でした。 今ではこれらに明確な答えが得られ、自信を持ってKubernetesクラスタへのIstio導入をお勧めできるようになりました。 様々なメリットがありますが、今回は私が最も気に入っているIstioのメリットを4つ紹介したいと思います。

本稿ではKubernetesのHorizontal Pod Autoscaler（HPA）のクイックハンズオンを行います。 Kubernetes上にシンプルなCPU負荷の高いWebアプリをデプロイし、そのデプロイのためにHPAを設定します。 その後、負荷テストを行い、設定したメトリクスに基づいてレプリカの数が自動的にスケールすることを確認します。

【明日から使えるヒント！】自分でやった方が早いから！を克服する　人を動かす力 というUdemyのコースが非常に勉強になったので、学んだことの一部をメモします。

全部でたった2時間。1.5倍速や2倍速だと通勤時間中に見終わる長さなのに、大事なことがたくさん学べました。かなり有益でしたので、ぜひお勧めします。

本記事ではコースの動機づけや概要について簡単に説明した後、学んだことを3点、要約の形で紹介します。

本ブログでは、NGINXの基本的な利用シーンである静的ホスティング、リバースプロキシ、ロードバランサについてまとめます。

また、それぞれのユースケースについて、Dockerを使った完全に再現可能な構成セットアップを提供します。

GatsbyJSでMarkdownを書くと，ファイル名がslug (URLの一部)になってしまいます．ファイル名は日本語にしたいが，slugは英語にしたい．また，slugを指定しない場合は通常通りファイル名から自動生成したい．これを実現する設定について説明します．

アーキテクチャシミュレータ gem5 には，Systemcall Emulation (SE) モードと Full System (FS) モードの2種類があります．
今回は，FSモードに必要な disk image を，Docker を使って作成する方法を紹介します．