kanuazutのblog

よわいエンジニアの備忘です

受験記:Google Cloud Certified: Professional Cloud Network Engineer

認定試験を受験したので体験記をまとめておきます。

試験概要

基本情報

公式ページ
Professional Cloud Network Engineer 認定資格  |  Learn  |  Google Cloud

Google CloudのNetwork関連サービスの知識を問う認定資格です。 ネットワーク サービス、ハイブリッドおよびマルチクラウド接続、VPC の構成設計・実装などの知識が求められます。

項目 内容
受験料 $200
試験時間 120分
出題形式 50 ~ 60 問の多肢選択(複数選択)式

受験目的

Google Cloudを業務利用するにあたってサービス知識を身に着けておくことは有用かと思い順番にGCP資格を取得していました。Network Engineerもその一環です。
試験範囲のハイブリッド接続などは必要にならないことも多いですが、ネットワークアーキテクチャの設計や実装などはクラウドを使う上で頻出のタスクだったりするので、有用な知識も多いと思います。

受験結果

項目 内容
受験日時 2024/05/12
場所 IBT (Kryterion)
結果 合格

合格でした。点数は未公開のため分かりません。

勉強に関して

事前知識

勉強開始前の知識レベルは以下の通りです。

  • 一般的なVPC, Cloud Compute, Cloud SQLの構成を構築したことがある
  • Google Cloud Certified PCA, PCD, PDE, PCSEを取得済み

勉強方法

勉強には以下のコンテンツを利用しました。

  • Cloud Skills Boost

総学習時間: 6h
総学習費用:なし

Cloud Skills Boost

www.cloudskillsboost.google

学習時間:6h

Cloud Skills BoostでCloud Network Engineerのラーニングパスを受講しました。
私はPartners向けサイトで受講したため無料でしたが、上記リンクが有償版の同等コースにあたると思います。

Cloud Skills Boostを利用したことが無い人向けに説明すると、基本的には動画講義で学習を進め、ラボ演習と練習問題が時々挟まってくるような一連のコースになっています。動画学習に慣れている人はおすすめです。ただし英語の講義が多いため、英語の聞き取りが難しい人は自動翻訳の日本語字幕で見ることになります。
Google Cloudが出している公式のラーニングパスなだけあって、教材の質は高く、試験範囲の網羅性も高そうでした。ラボ演習もあるため座学のみの教材に比べ実務に向けたスキルも身に付きやすいでしょうし、練習問題もあるのでしっかり学習したい人には向いていると思います。
一方でとにかく試験に受かりたい人には向いておらず、すぐ認定試験に受かりたい人はもっと時間効率の高い教材を探す必要があると思います。

ラーニングパスの全コースを順番に受講した場合の所定時間は約96時間とかなり長めです。実際には半分以上がラボ演習の時間なので、講義だけ視聴するならそこまでかかりません。 合格だけを考えるなら講義とミニテストだけ取り組めば十分かなと思います。

ラボ演習に取り組むとしても50時間もあれば終わるのではないかと思います。 私の場合はラボ演習はやらず、過去に他の試験で受講済みだったコース(Google Cloud Fundamentals: Core Infrastructureなど)も飛ばして1.5倍速で視聴したため、6時間で終わりました。

所感

試験に関して

難易度:★★☆☆☆

体感としては他のProfessinonalレベルの認定よりは比較的簡単な印象です。 必要な知識レベルは他のProfessionalと同等な気はしますが、

  • ネットワーク領域に閉じた内容
  • 出題される問題が、2択まで絞りやすい

という点から、個人的には他の認定よりは簡単に感じました。 逆に「VPN?BGP?何それ?」というレベルでネットワークに明るくない人は基礎知識の勉強が必要になり難しく感じるかもしれません。

問題は素直な内容が多く、文章を注意深く読み込まなければいけない問題はありませんでした。知識が身についていれば、まあこれだろうという選択肢を選べば問題ないと思います。
試験時間は2時間ですが、サクサク進めれば40分程度で終わるため見直しの時間は十分にありました。

Tips

試験ガイドにも記載がありますが、以下の内容は正確に理解しておくことをお勧めします。

  • Dedicated Interconnect と Partner Interconnectの違いと使い処
  • 共有VPC
  • HA VPN
  • Cloud Router
  • ロードバランサーの種類
  • ルーティングルールマップ
  • 限定公開Googleサービス、限定公開アクセス、限定公開コネクト
  • Cloud Armor
  • Cloud CDN
  • Cloud NAT
  • Network Intelligence Center, Cloud Monitoring, Cloud Logging, VPC Flow Log

問題によっては別の問題の問題文にヒントのある場合があるので分からない問題には「後で見直す」をつけておき、最後に見直すことをお勧めします。

2024年4月読書感想

4月に読んだ本の読書感想文です。

マルチクラウドネットワークの教科書

満足度:★★★☆☆

ハイブリッドクラウド、マルチクラウドを説明する数少ない本
AWS/Azure/Google Cloudの代表的なクラウドサービスについて、NW系サービスの設計ポイントを紹介している本です。
AWSの場合、Azureの場合、GCの場合と同じ分量でそれぞれのサービスの技術的特徴や仕様・制約が説明されており設計時の検討ポイントが理解しやすいです。
タイトルの通りですが、オンプレを含むハイブリッド構成から始まり、複数ベンダのクラウドサービスを接続する構成が説明されています。
マルチクラウドを説明する書籍自体が少ないと思うので、これからマルチクラウドの設計検討を始める人は助かると思います。

資格試験にも良いかも
また、各クラウドのネットワーク認定試験の勉強にも役立つと思いました。
特にAWS ANSやGC PCNEなどはNWに特化した書籍が少ないのもあって、サービスの基本情報確認には適しています。ただ3つのクラウドについて説明されているので勉強用途では冗長ではあります。

逆にネットワーク系の認定試験に合格している人であれば、
専用線接続とVPN接続の2つが大きな選択肢となることや管理負担を減らすためにハブスポーク型のNW構成をとることが重要なことなど、既知の内容が多いかもしれません。
私の場合は既知の内容が多かったので★3にしていますが、書籍の内容自体は良いものだと思います。



Figma for UIデザイン

満足度:★★★☆☆


始めてFigmaを使う人にも分かるように機能説明がされています。
全ての説明はカラーでスクショを交えて丁寧な説明がされているのでサクサク読み進めることが出来ました。

Figmaを適当にポチポチ触ってるだけでは知らなかった便利な機能として、制約やバリアントについて学ぶことが出来たのはよかったです。
この1冊を読めばひとまずFigmaでモックを作成するのに困ることは無いと思います。

Figmaについてはネット情報も多いため、自分で調べつつ使えうというスタイルが身についている人はそちらの方がいいかもしれません。
私の場合は情報収集が面倒だったのと体系的に機能の使い方を知りたかったので、この本に頼りました。

Microsoft Azureアプリ開発入門ガイド

満足度:★★★★☆

Azureでアプリ開発する手順を説明している本です。コードは.NETのコードとなっています。
本書で説明されているコードはどれも初歩的な内容ですが、各サービスの連携方法の足掛かりにするには十分だと思います。
前から順番に写経していくだけで、Azureにおけるサービス利用の理解がそれなりに進みました。

ただし、題材とするシステムアーキテクチャがあるわけではなく、個別サービスの利用方法という色が強いため、実際にアプリケーションを開発する場合はシステム全体構成を検討するスキルが別に必要になってくるとは思います。

また認定試験AZ-204の理解にもある程度役立つと思いますが、試験にでるようなサービスプラン仕様のような細かい部分は記載されていないです。
AZ-204のMS Learnの内容をより実践形式にしたものという感じがしたので相補的に使えると良いかもしれません。




満足度の判例

満足度 基準
★★★★★ 非常に満足。何度も読みたい。
★★★★ 満足。興味深い内容。人にも薦めたい。
★★★ 読んでよかった。何かしら新たな知見や洞察が得られた。
★★ 今の自分に必要な本ではなかった。
自分には合わない。読む必要はなかった。

受験記:Azure Developer Associate (AZ-204)

Azure Developer Associate (AZ-204)の認定試験を受験したので体験記をまとめておきます。

試験概要

基本情報

認定試験の基本情報です。

項目 内容
受験料 21102円
試験時間 100分
出題形式 択一選択、複数選択、並び替え

試験ガイダンスには以下のように記載されています。

この認定資格の受験者は、要件の収集、設計、開発、デプロイ、セキュリティ、メンテナンス、パフォーマンス チューニング、監視など、開発のすべてのフェーズに参加する責任があります。

Azure の次の項目に習熟している必要があります。

SDK データ ストレージ オプション データ接続 API アプリの認証と承認 コンピューティングとコンテナーのデプロイ デバッグ

Azureにおいて開発に必要な知識を学べる認定試験という感じで、対象サービスはやや広めですがそこまで深い知識は求められません。

詳細は公式ページをご確認ください。
なお認定名は「Microsoft Certified: Azure Developer Associate」ですが、認定を受けるために合格が必要な試験名は「Developing Solutions for Microsoft Azure」です。

受験結果

受験結果は合格でした。割とギリギリです。

項目 内容
受験日時 2024/05/05
場所 IBT (PearsonVUE)
結果 合格 752/700

勉強内容

勉強前の知識

  • AZ-104, SC-300, SC-500取得済み
  • Azureのサービス名を聞けば何のサービスかは分かる

勉強資料

MSLearn

勉強教材としては公式のMSLearnのみを利用しました。
説明文が機械翻訳なため分かりにくい部分もありますが、公式資料であるため出題範囲を満遍なく学べると思います。 現在はAZ-204試験用の書籍もないため、こちらが試験勉強の第一選択肢になりそうです。

私の場合はAZ-104に合格済みだったのでAzureの基本的な部分は把握しており、サクサク進めることができてMSLearn終了に10時間かかりませんでした。 MSLearnでは各トピック毎に小問題が出題されますが、実際の試験と比べるとかなり易しい問題だったので、その点は気を付ける必要があります。 MSLearnの学習のみで合格できましたので内容の網羅度合としてはMSLearnだけで十分なのだと思います。 ただ点数的にはややギリギリだったため、サービスのドキュメントなども含めてもう少し詳細まで勉強しても良かったかなと思います。

また、50問分の練習問題も用意されているため力試しに利用すると良いと思います。(私は時間がなくて取り組めませんでした)

所感

難易度:★★★☆☆

AZ-103やSC-300よりはやや難しく感じました。
出題形式等は他のAzure認定試験と同様です。

構築の流れを問う問題、サービスプランの仕様を問う問題、要件に適するアプローチを問う問題などいつもの問題でした。 コードの記述を選択する穴埋め問題も出題されましたが、サービス間連携の流れなどが分かっていれば解ける問題が多かった印象です。

試験言語はPythonC#を選ぶことが出来ます。私は普段Pythonを使っていますが、MSLearnの説明がC#および.NETのAzure SDKを利用したものだったこともあってC#で受験しました。 コードの穴埋め問題なども出題されますが、10行程度のコードで言語仕様を理解している必要はありませんでした。Python, C#を選んだときの違いはライブラリ名やクラス名の違い位だと思います。 MSLearnで勉強した人はC#の方がオススメです。

App ServiceやBlob Storage, CosmosDB, Key Vault, Entra IDとの連携など実際の開発で多用するであろうサービスが主な出題範囲となるため、勉強内容は役立ちそうです。

memo:Reactの画面分割ライブラリ

よわよわエンジニアが知ったことのメモ日記です

ことの発端

Next.jsを使っていて、画面を右と左に2分割して使いたい。 当然ながらCSSで頑張れば実装は可能だと思うが、Reactのコンポーネントライブラリで簡単に作れるものがないか探したいというのが発端。

結構あるあるのユースケースだし幾らでも記事でてくるだろうと思っていたら、案外日本語の使ってみた系のページが少なかったので、机上調査をまとめておく。

一部動作確認した時の環境は以下の通り

+-- @types/node@20.9.4
+-- @types/react-dom@18.2.17
+-- @types/react@18.2.38
+-- next@14.0.3
+-- react-dom@18.2.0
+-- react-split-pane@2.0.3
+-- react-split@2.0.14
+-- react@18.2.0
`-- typescript@5.3.2

最終的に使うことにしたのは react-split-pane
簡単に使えそうだったので最小労力でやりたいことが出来るものとして選択した。

split

github.com

Star 5.9k。Sopnsorもついていて安定していそうな印象を受けた。 Split.jsをReact Component化したものっぽく有名どころが元となっている点も良い。

日本語の記事もあった

公式をコピペしてやってみたけど、スプリットされない。。

<Split
    sizes={[25, 75]}
    minSize={100}
    
    expandToMin={false}
    gutterSize={10}
    gutterAlign="center"
    snapOffset={30}
    dragInterval={1}
    direction="horizontal"
    cursor="col-resize"
>
    <div style={{border:1, color: 'red'}}>aaa</div>
    <div style={{border:1}}>bbb</div>
</Split>

本当は2つのdivが左右に分かれるはずなのだが、divの中身が縦に二つ並んでしまう。スプリットの境界をドラッグすることも出来ず、境界線も表示されなかった。 特にエラーも出ていなかったのだが、Reactのバージョンが問題かもしれない。

react-split-pane

github.com Star 3.1k。こちらも日本語の記事が数件存在していた。

インストールしようとしたが、エラーが出た。 どうやら最近のReactには対応していないらしい。

$ npm install react-split-pane --save
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: proto@0.1.0
npm ERR! Found: react@18.2.0
npm ERR! node_modules/react
npm ERR!   react@"^18" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.0.0-0" from react-split-pane@0.1.92
npm ERR! node_modules/react-split-pane
npm ERR!   react-split-pane@"*" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! 
npm ERR! For a full report see:
npm ERR! /root/.npm/_logs/2023-11-26T02_50_51_639Z-eresolve-report.txt

公式画面の一番下の方に書いてあった。

こっちでインストールしたら "react-split-pane": "^2.0.3" が入って一応動いた

react-split

github.com

Star 52で若干不安。中文。 ただデモページもあり、更新も一人が頑張っているっぽい。 - uiwjs.github.io

react-grid-layout

github.com

npmtrends.com

このページによるとreact-grid-layoutの方が勢いがあるらしい。 今回のケースではちょっと多機能すぎるので、採用は見送ったがこれがデファクトっぽい。

memo:Tell mode, Ask mode

Tell mode, Ask mode

ある本を読んでいて「Tell mode, Ask mode」という知らない単語を見かけたので調べた。
本の中ではリリース手法とブランチ戦略についての解説に登場した文言。

結論から言うとTesk Mode, Ask Modeはコード品質を上げるためのプロジェクト管理の方針の一つ。
Tell Mode, Ask Modeともレビューを厚めに構えることでチェックイン頻度を下げ品質を担保するという考えがベースとなっている。
現代のスピーディな開発やCICDの流行りには逆行するような方針にも見える。個人的には今もマージリクエストによるレビュープロセスは標準的であるが、Tell Mode, Ask Modeはチェックイン頻度を下げることを目的として明言している点で今の開発プロセスと着眼点が異なると思う。(調べたところ見つかった記事は2004年, 2015年のものなのでやや古い考えかもしれない。日本語の記事もなかったため普及しなかったのだろうか。)

定義としては以下のようなもの。

Tell Mode
部門内のチームには、好きなようにバグを修正する裁量が与えられる。ただし、そのバグを選んだ理由をShiproom*1で発表・説明する必要がある。
そうすることで、事業部内の共通のハードルが確保され、修正のスピードが遅くなり、徐々にビルドクオリティが上がる。

Ask Mode
部門内のチームはチェックインする前にShiproomの許可を得る必要がある。
askモードのバグは、夜間の自動化テストとバディテストを経て、問題の発生を防ぐ必要がある。

見ての通り、チェックインにブレーキをかけることで品質を担保しようという方針であるため、トレードオフと適不適がある。
この手法の背景としてあるのは、大規模プロジェクトにおけるリグレッション起因のバグ再発ループである。思うに「開発者が大した影響のないバグにも修正を試みて新たなバグを生んでしまうという状況が品質の低下につながってしまう」という考えから、修正対象を選んだ理由を説明させるTell Modeと修正を承諾制にしたAsk Modeが生まれたのではないか。

こういったプロセスを導入することで、開発者がバグを修正する前に「なぜそのバグを修正するのか」を自発的に考える習慣が生まれるのは良いことだと思う。

参考文献

*1:バグが検討・評価され修正するかどうか判断するデイリーミーティング。恐らくミーティングではなく特定のマネージャの判断で代替することも可能

memo:Chatty vs Chunky

Chatty vs Chunky

ある本を読んでいて「Chatty Design vs Chunky Desgin」という文言を見かけた。API設計の文脈で登場した言葉である。
聞き馴染みがなかったので調べてみたが、日本語のサイトがこちら*1くらいしか見つからなかったのでちょっとまとめておく。
検索でトップに出てきたワシントン大学のページによれば、以下のような定義らしい。

Chatty services tend to be ones that return simplified information and use more fine-grained operations.
Chunky services tend to return complex hierarchies of information and use coarse operations.
In other words, the difference is that chatty services require more calls than chunky services to return the same information but allow more flexibility to return only the information that is actually required.

またある学習サイトでは、以下のように説明がある。

Chatty API is one that requires consumer to make tremendous (subjective matter) amount of distinct API calls to get needed information about a resource.

雑にChattyとChunkyを日本語で再定義すると以下のような感じだと思う。

Chatty(おしゃべり)
 サーバで最低限の処理のみ実行し最低限の出力を返す
 ChattyなAPIでは目的を果たすためのリクエスト回数が多くなる

Chunky(かたまり)
 サーバでまとまった処理を実行し最終的な出力を返す
 ChunkyなAPIでは目的を果たすためのリクエスト回数は少ない


単純な例としては、100万件のデータを持つシステムがあったときに

  • ChattyなAPIでは100件ずつ1万回GETリクエストを投げる
  • ChunkyなAPIでは100万件のデータを一気に取得するGETリクエストを投げる

などが考えられると思う。
Chattyだと1万回もリクエスト投げなきゃいけない。そりゃもはや攻撃だよねと思いつつ、
Chunkyだと100万件のデータを一気に取得するのもそれはそれでどうなの?
ということで、常にChattyがいいとかChunkyがいいとかではないよう。
当然ながらどちらの設計が良いのかはアプリケーションに依存するし、リクエストレート制限やデータ量制限などと併用して設計する必要があるよねということが前提。


とはいえ、MiscroSoftのページでも、以下のように言及がある。

Network calls and other I/O operations are inherently slow compared to compute tasks. Each I/O request typically has significant overhead, and the cumulative effect of numerous I/O operations can slow down the system. Here are some common causes of chatty I/O.

要するにChattyなAPIは、ネットワークコールやI/Oの回数が増えるとオーバーヘッドが増え、ネットワークにもシステムにも負荷がかかるということ。
極度なChattyはシステムに負荷を掛けかねないので、一般的には避ける傾向にあるようだ。
最近のハードウェアはある程度のデータチャンクに耐えうるCPUやメモリを搭載しているので、Chunkyでもリクエストの待ち時間はそこまで大した時間にはならない。その一方でネットワークは高帯域を備えていないことも多く問題になることも多いのかもしれない。