2024 年 10 月から約 3 ヶ月に渡り Google Cloud が主催する Google Cloud Innovators Gym #9（通称 G.I.G.）というプログラムに参加してきたので、振り返りも兼ねてブログを書きたいと思います。 今後参加される方や、Google Cloud 認定資格試験を受けようと考えている方に向けて、何かの参考になれば幸いです。

Google Cloud Innovators Gym (G.I.G.) #9 参加レポート

システムの監視は安定した運用を維持するために欠かせない要素です。 モニタリングの一環として「アラーティング（警告通知）」を整備することで、システムの異常を早期に検出して適切な対応を取ることでダウンタイムの回避やパフォーマンスの最適化を図ることができます。今日、Grafana は OSS として公開されているダッシュボードツールのデファクトスタンダードとなっています。 Grafana はメトリクスの可視化やデータ分析の機能だけでなく、アラート機能を活用することでシステムの異常をリアルタイムに検出し、担当者に迅速に通知することが可能です。 最新の Grafana バージョンでは、アラート機能が大幅に強化され複雑な条件設定や通知チャネルの多様化に対応しています。Grafana Alert は単純なクエリや閾値に加え、ポリシを設定することで通知のタイミングを柔軟に制御することができます。今回のブログでは、Grafana Alert の機能について基本的な仕組みやアラートの制御方法について整理したいと思います。

Grafana Alert の機能を整理してみる

Kubernetes には Pod の配置を制御する機能があります。 Pod の配置制御とは、任意の Pod を特定のノードにスケジュールしたり、逆に特定のノードに対して Pod をスケジュールさせないようにコントロールすることです。最も簡易的な方法として、Node Selector を使用することで任意の Pod を所定のノードにスケジュールすることができます。 また、Node Selector に加え、より細やかな制御が可能な Node Affinity を使用することもできます。Node Selector および Node Affinity が、ある Pod を特定のノードにスケジュールさせるために使用されるのに対し、Pod をあるノードから遠ざけたい、または特定のノードをワークロードから隔離したいという要件に対しては Taints/Tolerations という機能が用意されています。 Taints と Tolerations は互いに作用しあい、Pod が不適当なノードにスケジュールされるのを防ぎます。Node Affinity の場合は、未指定の場合、どのノードにでも Pod をスケジュール可能ですが、Taints/Tolerations の場合は、指定しない限りそのノードに Pod がスケジュールされることはありません。Taints/Tolerations は、例えば Production 用のノードには他の Pod をスケジュールさせたくない場合や、GPU（Graphics Processing Unit） や FPGA（Field Programmable Gate Array） 等の特殊なデバイスを持つノードには特定の Pod 以外をスケジュールさせたくないといった場合に有効です。今回のブログでは、Taints/Tolerations による Pod の配置制御とノードの隔離策についてまとめたいと思います。

Taint/Toleration による Pod 配置制御とノードの隔離

Kubernetes API はクラスタリソースを操作するための基本的なインターフェースを提供します。 クライアントは Kubernetes API を通じて、Namespace, Deployment, Pod 等の Kubernetes の様々なオブジェクトを検索・操作することができます。Kubernetes API はクラスタのアップグレードに伴い、既存の API が非推奨（Deprecated）または廃止（Removal）となる場合があります。 もし、非推奨 API でサービスを運用し続けると、いずれ API が使用できなくなりサービスのダウンタイムや障害を引き起こすリスクが高まります。 実際に米国ソーシャルニュースサイト Reddit の例 にあるように、非推奨 API を使用し続けたことで大規模な障害が発生した事例も報告されています。Kubernetes の API サーバは API のバージョン情報を管理しており、Deprecated API を適用すると、以下のようなメッセージで警告を出してくれます。これは v1.21 のクラスタに対して、batch/v1beta1 の CronJob を利用したリソースを定義したマニフェストを Apply した際に返される結果です。 kubectl が Warning を返しているのが分かると思います。今回のブログでは、Kubernetes が非推奨 API を検出する仕組みについて紹介したいと思います。

Kubernetes が非推奨 API を検出する仕組み

Kubernetes はコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための強力なプラットフォームエンジンです。 マニフェストを用いてリソースの種類や制御パラメータを組み合わせることで、アプリケーションを柔軟にデプロイ・管理できますが、運用面での統制やセキュリティの確保が課題となっています。 組織全体で一貫したポリシを確立し、セキュリティ要件を設けることは、運用の安全性を確保する上で非常に重要になります。また、インフラ・プラットフォームサイドのエンジニアが継続的に介入せずとも、開発者が自立して安全にアプリケーションを開発できるように舗装することは Platform Engineering の文脈でも必要になってきます。今回のブログでは、ポリシ整備ツールのデファクトスタンダートとなっている OPA（Open Policy Agent） および Gatekeeper を取り上げ、Kubernetes に対するデプロイメントを制御する仕組みについて紹介したいと思います。

OPA で実現する Kubernetes のポリシ制御

Google Kubernetes Engine（GKE）は Google Cloud が提供するマネージド Kubernetes サービスで、クラウドネイティブなアプリケーションの実行基盤として広く利用されています。 Kubernetes クラスタの運用において、アップグレード作業はセキュリティの確保や新機能の利用のために不可欠なプロセスです。一方、Kubernetes のマイナーリリースは 通常 3 - 4 ヶ月に 1 回のペースで実施される上、アップグレード作業にはいくつもの考慮事項があるため、メンテナンスコストが高くなりがちです。また、マネージド Kubernetes の場合、サポートを受けられる期間も限られているため、継続的なクラスタバージョン追従が必要になります。このような GKE のメンテナンスに関する課題に対して、Google Cloud は作業負荷を下げるための仕組みを用意してくれています。このブログでは、GKE の効果的なアップグレード戦略について Google Cloud の内間さんが出している こちらのスライド を参考にまとめてみます。

GKE のアップグレード戦略を考える

先日開催された Qiita Hackathon 2024 に参加をし、無事に予選を通過してきたので、振り返りも兼ねてブログを書こうと思います。

Qiita Hackathon 2024 に参戦してきました

GCP では各マネージドサービスを利用する際の権限管理としてサービスアカウント（GSA：Google Service Account）を用います。GSA には、予め Google 側で用意しているデフォルト GSA と、利用者が自由に作成できる GSA が存在します。一般に、前者のデフォルト GSA はプロジェクト作成時点や API を有効化した際に自動的に作成されます。デフォルト GSA は削除してしまうと、その GSA を利用するマネージドサービスにアクセスできなくなってしまいます。今回は、誤って削除してしまったデフォルト GSA の復元方法について紹介したいと思います。

誤削除したデフォルト GSA の復元方法

近年、フロントエンドアーキテクチャとして Feature-Sliced Design（FSD） と呼ばれる設計手法が注目されています。 FSD は、特にマイクロサービスを採用しているような大規模かつ複雑なシステムの開発現場において、生産性の向上が期待されており、アジャイル法や DevOps との親和性も高いとされています。FSD はシステムを構成する機能や特性（Feature）を スライス（Slice） と呼ばれる単位で細分化し、それぞれが独立性を持つことで全体の設計や変更を容易にするというものです。 スライスの考え方により、複雑な機能を把握しやすくなり、サービス規模拡大に伴うスケーラビリティを担保することが期待されています。FSD は、言語問わずあらゆるフロントエンドアプリケーションに適用できますが、今回は特に Web フロントの設計に焦点を当てて紹介したいと思います。

FSD ベースのフロントエンドアーキテクチャ

8 月 1 - 2 日（2 Days）パシフィコ横浜にて開催された Google Cloud Next Tokyo'24 に現地参加してきました。基調講演では主に生成 AI の最新動向や将来性について、実際の活用事例や今後の展望、使用していく上での課題や解決策に関する話題がメインでした。今回のブログでは、基調講演をはじめ、いくつか気になったセッションに関してまとめようと思います。

Google Cloud Next Tokyo'24 現地参加レポート

マルチクラウド環境において、AWS から GCP のマネージドサービスに対し、OIDC によるキーレス連携を実現する GCP Workload Identity Federation の仕組みについて紹介します。多くのクラウドサービスでは、API キーや Credential（AWS アクセスキーや GSA アカウントキー）を発行することで、各種マネージドサービスにアクセスすることが可能です。しかし、永続的に使用できてしまう認証情報は、キーローテーションによる管理の煩雑化や、流出によるセキュリティリスクが存在します。GCP Workload Identity Federation では、Credential として有効期限の短い STS トークンで認証・認可を行うため、前述のセキュリティリスクを軽減できます。これらの処理はクライアントライブラリによって隠蔽されるため、サービスの開発者やワークロードは OAuth 2.0 Token Exchange の複雑な仕組みを意識することなく、通常の Credential と同じように利用することができます。GCP Workload Identity Federation は非常にセキュアで利便性が良いですが、内部でどのような手続きが行われているのか気になったので DeepDive してみました。

Workload Identity Federation の仕組み

5 月 28 - 30 日（3 Days）Google Cloud が開催する Platform Engineering のハンズオンセミナーに参加してきました。 今回のセミナーは Google Cloud カスタマーエンジニアの公演を聞きながら、Google Kubernetes Engine（GKE）を活用して実践的に Platform Engineering を学ぶコンテンツとなっており、座学とラボの両方が実施されました。今回のブログでは、振り返りも兼ねて 3 日間の参加レポートをまとめたいと思います。

Google Cloud を活用した Platform Engineering の実践

サイバーエージェント新卒研修にて『生成 AI を用いた SNS』というテーマで 3 週間の短期開発に取り組みました。僕たちのチームは 'AI で生成した美女' を共有する SNS アプリケーションを開発し、成果発表では インフラ部門で技術賞 を頂きました。今回のブログでは、開発したサービスと実際に構築した運用アーキテクチャについて設計思想や技術選定を交え、紹介したいと思います。

新卒研修で構築したサービス運用基盤の紹介

Hi there, Happy New Year! 🐉 I'm about to embark on a journey that's both for an IEEE international-conference and my graduation trip. My destinations: Hawaii (Oahu) and Las Vegas, USA. The International-Conference on Consumer Electronics (ICCE) and Consumer Communications & Networking Conference (CCNC) are academic conferences hosted by Institute of Electrical and Electronics Engineers (IEEE). These events focus on discussing the latest research and technological advancements in consumer electronics and communication technologies. Last year, my demonstration paper was accepted at CCNC 2024. I will be presenting the concept of the CYPHONIC adapter demonstration, which I've been researching and developing. A few of my colleagues will also be presenting at the conference. After the international-conference, I plan to visit CES 2024 as well. I'll be updating this blog daily as a travel diary. Alright-off I go! ✈️

IEEE International-Conference Trip in Hawaii and Las Vegas

株式会社 AbemaTV Cloud Platform Team にて ABEMA を構成するマイクロサービスのデプロイ状況を可視化するモニタリングツールの開発・導入ミッションに臨みました。本記事は 「CyberAgent Developers Blog - ABEMA におけるマイクロサービスデプロイ状況可視化のための内製モニタリングツールの開発」 に掲載された内容です。

ABEMA に内製モニタリングツールを導入した話

クラウドサービスや Third-party ベンダが普及する昨今、各サービスを連携する上で、OIDC や OAuth 2.0 という言葉をよく耳にすると思います。これらの仕組みは、サービスを利用する際のセキュリティを担保する上で重要となる、認証・認可を提供するための基本的な規約（プロトコル）になります。OAuth 2.0 や、その仕組みを流用して拡張された OIDC は複雑で、認証・認可において多くのフローを辿ります。毎回、再調査をするのが大変なので、認証・認可の仕組みについて一度整理しておきたいと思います。

OAuth 2.0 プロトコルに基づく認証・認可

現在、研究室で利用するための KaaS 基盤（プライベートクラウド）を整備するべく、ベアメタル Kubernetes の構築に取り組んでいます。今回は、CNCF cloud native landscape にもある Rook/Ceph を使用して分散ストレージシステムを導入し、Amazon S3 や Google Cloud Storage に相当するオブジェクトストレージを自前で構築してみたので、その紹介です。

Rook/Ceph で実現する分散ストレージの構築

Kubernetes やクラウドネイティブな環境下での負荷試験において、Grafana Labs の k6 が注目されています。 k6 はコンテナフレンドリーな設計となっており、シナリオの定義も非常に容易です。 また、Kubernetes への導入には、オペレータ（k6-operator）を用いることで、大規模な負荷シナリオや分散実行、自動化されたパイプラインとの統合も可能です。今回のブログでは、モダンな負荷試験ツールである k6 を取り上げ、導入方法や負荷試験環境の構築についてまとめてみたいと思います。

k6 で実現する負荷試験のモダナイゼーション

こんにちは！れん（@ren510dev）です。今年も近所の桜が満開で、外に出ると香りが漂ってきます。夜は過ごしやすい気温だし、風も気持ち良いので 最近は毎日 1 時間程散歩をしています。健康に良いし、考えも整理出来るしで一石二鳥！丁度 1 年前の 2022 年 4 月 ~ 2022 年 7 月にかけて、インターンシップを始め就職活動を行い、計 40 社 以上の面談・面接を受けました。結果、多くの企業よりオファーを頂き、インターンの合格通知、内定を獲得することができました。最近では、25 卒の方から、選考対策・就活に関する相談を受けることも多くなってきたので、今回は当時を振りつつ、経験を踏まえてこれから就活を始める人に向けてメッセージを書いてみようと思います。

【What's my color?】自分のイロを探す旅

3 年ぶりに Orenge Diary をフルスクラッチリニューアルしました。これまで、jQuery と PHP をベースに Nginx on KVM（Ubuntu）でセルフホスティングしていましたが、モダンな Web フロントアーキテクチャを目指して Next.js へリビルドし、Vercel に移設しました。今回のブログではポートフォリオサイトのリビルドについて軽く紹介したいと思います。

Orenge Diary をリビルドしました

Next.js は、React ベースの Web アプリケーションフレームワークで、SSR（Server Side Rendering）等のフロントエンド開発に必要な機能を十分に備えています。 2022 年 10 月には、App Directory（App Router）というルーティングエンジンを beta 版として導入した Next.js 13 がリリースされました。今回のブログでは、Next.js 13 の基本的な考え方と使い方について整理してみたいと思います。

Next.js 13 でリリースされた機能の紹介

従来、Kubernetes では秘匿情報を管理するコンポーネントとして KES（Kubernetes External Secrets） が広く利用されており、Secret リソースを管理するツールとしてデファクトスタンダートとなっていました。 しかし、2021 年 11 月 KES の非推奨化が発表され、2022 年 7 月時点でアーカイブされました。KES が非推奨になった背景としては、アクティブなメンテナがいなかったことや、プロジェクト内で抱えていた技術負債を解消しきれず、メンテナンスのモチベーションを維持できなかったことが言及されています。KES の非推奨化に伴う後継ツールの一つとして ESO（External Secrets Operator） が注目を集めています。 ESO は KES を開発していたコミュニティによってホスティングされており、Go でリファクタリングされています。 ESO は KES との互換性を維持しつつ、メンテナンス性を重視した機能豊富なサービスとなっており、移行ツールも用意されています。今回のブログでは、KES の非推奨化に伴う ESO への移行について、ツールの特徴を交えながら紹介したいと思います。

KES 非推奨に伴う ESO への移行

Ubuntu 22.04（LTS）がリリースされたのでインストールしてみましたが、そのまま放置して数ヶ月が経っていました。 久しぶりに使用する場面が来たので、いつも通り apt update しようとしたところ、『Warning: apt-key is deprecated』というメッセージが表示されました。Debian 12 からは、apt パッケージの署名に利用している apt-key が非推奨・廃止になるとのことです。しかし、今のところ、apt-key に変わる、apt リポジトリの署名に使用する GPG 公開鍵の管理手法におけるベストプラクティス的なものが無かったので、とりあえず、GnuPG（gnupg + signed-by） で移行してみました。

apt-key 非推奨に伴う gnupg への移行

Go 1.18 は「our biggest change ever to the language」と言われるほど、Go 言語誕生以来、最大の仕様拡張が行われました。中でも、netip パッケージの登場は Go でネットワークプロトコルを書いている身として非常に画期的だと思いました。今回のブログでは、netip の導入背景を踏まえ、パッケージの特徴、互換性、メソッドの使い方等、従来の net パッケージと何が変わったのかを紹介したいと思います。

Go 1.18 で追加された net/netip パッケージ

ゲーマー向けのテキストチャットサービスとして有名な Discord は、内部コンポーネントの一つである「Read States」を Go から Rust に再実装し、パフォーマンスが大幅に向上したことを発表しました。Discord のホットパスである「Read States」は、特に膨大なリクエストを捌く必要があり、システム自体に高いパフォーマンスが要求されるコンポーネントだそうです。 これまで、Discord の大部分は Go で実装されていましたが、2020 年初頭に Rust へ移行したことが明らかになりました。最近、Rust のキャッチアップをしていることもあり、なぜ、Discord は Go から撤退して Rust を採用したのか気になったので、公式ブログ を参考にまとめてみたいと思います。

Discord が Go から Rust に移行した背景を覗く

Web サーバやミドルウェアには、同時に多数の接続を効率的に処理することが求められます。 特に、インターネットの普及に伴い Web サービスの利用者が増加し、膨大なクライアントからのリクエストを処理する必要性が高まっています。Apache に代表される、スレッド（プロセス）駆動ベースのソフトウェアアーキテクチャは、増大するクライアントに対するリソースの消費傾向やコンテキストスイッチのオーバーヘッドが増大することで、スケーラビリティの課題があります。このような課題は、一般に C10K（同時に 10,000 接続を処理する）問題 と称され、2000 年初頭から、従来のソフトウェアの潜在的な課題を解決する効率的なアーキテクチャの必要性が議論されるようになりました。近年では、ソフトウェアにおけるイベント駆動ベースのアーキテクチャが注目され、Nginx のような新世代の Web サーバも登場しました。今回のブログでは、スレッド駆動ベースの Apache と イベント駆動ベース Nginx を例に、スレッド駆動アーキテクチャとイベント駆動アーキテクチャの特徴や、それぞれの技術的な問題点・利点について紹介したいと思います。

C10K 問題とソフトウェアアーキテクチャの変遷

Go を書いたことがある人なら、Goroutine というワードを耳にしたことがあるかと思います。Goroutine とは、Go で並行処理を実現するための軽量なスレッドのことです。Goroutine は一般的なカーネルスレッドと比較して、非常に軽量かつ効率的なスケジューリングが可能です。今回のブログでは、Go ランタイムの仕組みを覗き Goroutine が '軽量スレッド' と呼ばれる理由についてまとめてみたいと思います。

Goroutine はなぜ軽量スレッドと称されるのか

ネットワーク経路上のルータ（ソフトウェアルータ）をはじめとし、ロードバランサやキャッシュサーバ等のミドルウェアは、特に高いパケットレートを処理する必要があります。 これらのシステムは、膨大なパケットを迅速かつ効率的に処理するために、物理および論理の両方で高いパフォーマンスが要求されます。ネットワークトラフィックの処理は、コンピュータシステムにとって非常にリソース集約的な作業であり、高パケットレート環境下では CPU に掛かる負荷が非常に大きくなってきます。 ネットワークミドルウェアでは、多数のクライアントからの要求を捌くために、マシン内の処理に起因する負荷を効率的に分散・軽減させる必要があります。アプリケーションをマルチコア環境でスケールさせる際、CPU 負荷が特定のコアに集中することでシステム全体のパフォーマンスが低下する場合があります。 この問題を解決するため、Linux ネットワークスタックの NAPI や NIC のオフロード機能が、CPU の割り込み処理を効率化し、パフォーマンスを最適化する上で重要な役割を果たします。また、マルチコアスケーリングを効果的に実現するためには、NIC の RSS やカーネルの RPS/RFS といった機構も活用する必要があります。 これらの技術により、パケット処理を複数の CPU コアに分散させ、システム全体のパフォーマンスを最適化することが可能です。今回のブログでは、高パケットレート環境下において膨大なリクエストデータを捌くために Linux カーネルが取った対策について紹介したいと思います。

高パケットレート環境下におけるネットワークスタック最適化

このブログは『RaspberryPi で構築する Bare-Metal Kubernetes』のエコシステム編です。 準備編では、機器類の準備、セットアップ、各種 OSS の選定と全体設計について紹介しました。 また、構築編では Kubernetes クラスタを構築し、アプリケーションをデプロイして MetalLB で公開しました。エコシステム編では、より本番環境に近い Kubernetes の運用を目指すべく、モニタリング基盤と ArgoCD による GitOps を整備したいと思います。

RaspberryPi で構築する Bare-Metal Kubernetes - エコシステム編

このブログは『RaspberryPi で構築する Bare-Metal Kubernetes』の構築編です。 準備編では、機器類の準備、セットアップ、各種 OSS の選定と全体設計について紹介しました。構築編では、セットアップした RaspberryPi に Kubernetes をインストールして Control-Plane 1 台、Data-Plane 3 台のクラスタを構築し、アプリケーションをデプロイして公開してみます。 本記事では MetalLB の仕組みについても簡単に紹介します。

RaspberryPi で構築する Bare-Metal Kubernetes - 構築編

クラウドネイティブ に注目が集まる昨今、コンテナオーケストレーションツールとして Kubernetes がデファクトスタンダードな基盤技術となっています。 Kubernetes を用いることで 宣言的な設定（Declarative Configuration）に基づいたアプリケーションのデプロイ、管理、運用の自動化、スケーラビリティの確保等を実現することができます。Kubernetes によりサービス運用の効率化や高度な自動化を実現できますが、内部のアーキテクチャは非常に複雑なものになっており、コンピュータサイエンスの基本的な知識も必要になります。 運用に際して、インフラエンジニアやクラスタの管理者は Kubernetes の内部コンポーネントの詳細や、その挙動を熟知しておくことが重要です。Kubernetes の有名な学習リソースの一つに Kubernetes The Hard Way というものがあります。 これは、手作業で一からクラスタを構築して Kubernetes の内部構造への理解を深めるというコンテンツです。Kubernetes The Hard Way では、主に GCP の Compute Engine を用いますが、今回は RaspberryPi をベースにベアメタルでクラスタを構築してみました。 いわゆる『おうち Kubernetes』というやつです。今回は、RaspberryPi で Kubernetes をセルフホスティングする方法について 『準備編』『構築編』『エコシステム編』 の 3 編にわたり紹介したいと思います。 準備編では、機器類の準備、RaspberryPi の初期設定をします。 また、Kubernetes の構築に必要となる各種 OSS の選定や、ネットワーク構成およびインフラ全体の設計について固めます。

RaspberryPi で構築する Bare-Metal Kubernetes - 準備編

Go で競プロに臨んだ際、fmt.Scan で TLE が発生したので、その原因と解決策について fmt パッケージの Scan 関数と bufio パッケージの Scanner メソッドに注目しながらまとめてみます。

Go 言語における Scanning の特性と使い分け

インターネットを介して提供されるサービスはどのように構築・実現されるのでしょうか。現代のネットワークアプリケーション開発において、Socket API は非常に重要な役割を果たします。 Socket API は、異なるコンピュータ間でデータを送受信するための低レベルインターフェースを提供し、TCP/IP に則った通信を実現します。今回のブログでは、ネットワークソケットについて触れ、Socket API の概要から実際の使用法について紹介します。

ネットワーク通信の裏側と Socket API

日本で IP-Clos が採用されているヤフーにて Clos ネットワークの構築を経験してきたので、聞いた話や知見を含め IP-Clos について紹介しようと思います。

IP-Clos で実現するスケーラブルな DC ネットワーク

ソースコードだろうと論文だろうと VSCode で全てを完結させたい！今回は、mactex-no-gui というパッケージを導入して VSCode に Tex 環境を構築してみました。

brew + VSCode で TeX 環境を構築する

今日、インターネットは電気や水道と同じく日常に欠かせないインフラとなっています。 我々はスマートフォンやパソコンといったネットワーク機器を Wi-Fi やモバイル回線（5G や LTE）に接続することで、インターネットを通じて世界中の人と容易に繋がることができます。では、インターネットは一体どのようにして我々のもとに情報を届けているのでしょうか？今回のブログでは、インターネットやコンピュータネットワークの仕組みを紹介します。

インターネットの仕組みと TCP/IP

2020 年 11 月〜2021 年 3 月の約 5 ヶ月間、株式会社サイバーエージェントが企画する長期育成型プログラム CA Tech Accel という企画に参加をしたので、取り組んだこと、成果についてアウトプットしてみようと思います。

エンジニアとしての第一歩を踏み込んだ瞬間

開発の中で Linux 環境での検証が必要になったので、macOS に VirtualBox をインストールし、Ubuntu を仮想マシンとして立てて利用していました。 ところが Docker を多用していたところ、Docker イメージが思いの他ストレージを占領するため、あっという間にオーバーフローしました。 ということでそれまで 20 GB の仮想 HDD をアタッチしていましたが、これを機に一気に 64 GB までストレージを拡張していきたいと思います。今回は調べた内容を元に、Ubuntu 仮想マシンのストレージ拡張方法 について書き残しておきたいと思います。

Topics

Blog

Blog

Blog

Certification

Blog

Certification

Certification

Blog

Blog

Blog