2026-09-26

Google Cloud Professional Cloud Architectを受けてみた

この記事はなに？

2026年8月に、Google Cloudの認定資格であるProfessional Cloud Architect（以下PCA）を受験して合格したので、試験の概要、対策としてやったことをまとめてみました。

自分はGoogle Cloudの実務経験がない状態から、期間1ヶ月・実質30時間程度の勉強で受験しています。似たような立場の人の参考になるかもしれません。

注意点

記事の内容は2026年9月時点の情報です。PCAは2025年に大きく改訂されているので、古い受験記を読む際は気をつけてもらえるとよいかと思います
この記事の作成（下書き）にはAIを用いています

試験の概要

PCAはGoogle CloudのProfessionalレベルの認定資格で、ざっくり言うと「ビジネス要件を満たすシステムをGoogle Cloud上でどう設計・運用するか」を問う試験です。

公式の認定ページに記載されている概要は以下の通りです。

項目	内容
試験時間	2時間
問題数	50〜60問の多肢選択（複数選択）式
受験料	$200（税別）
言語	英語、日本語
受験方法	遠隔監視オンライン試験、またはテストセンターでのオンサイト監視試験
認定の有効期間	2年間
推奨される経験	業界経験3年以上（Google Cloudを使用したソリューションの設計と管理の経験1年以上を含む）
必須条件	なし

出題範囲は、試験ガイドでは以下の6つのセクションに分かれています。

クラウドソリューションアーキテクチャの設計と計画
クラウドソリューションインフラストラクチャの管理とプロビジョニング
セキュリティとコンプライアンスに対応した設計
技術プロセスやビジネスプロセスの分析と最適化
クラウドアーキテクチャの実装の管理
ソリューションとオペレーションの卓越性の確保

また、試験ガイドではGoogle Cloud Well-Architected Frameworkの知識が重要な要件として挙げられています。

ケーススタディ

PCAで特徴的なのがケーススタディです。架空の企業のシステムと要件が書かれたドキュメントが4つ、事前に公開されていて、試験前に読み込むことができます。ケーススタディに関する問題は試験全体の20〜30%を占めるとされています。

現行のケーススタディは以下の4本です。

Altostrat Media: 動画配信プラットフォーム
Cymbal Retail: ECサービス
EHR Healthcare: 医療系システム（SaaS）
KnightMotives Automotive: 自動運転

ここは注意が必要なポイントで、2025年10月30日の改訂によって、それまで使われていたMountkirk Games / TerramEarth / Helicopter Racing Leagueに代わる形で、Altostrat Media / Cymbal Retail / KnightMotives Automotiveが新たなケーススタディとして追加されています（EHR Healthcareについては変更無し）。

日本語の受験記や対策記事は改訂前のものがまだ多いので、ケーススタディの名前が出てくる記事を見つけたら、まず書かれた時期を確認した方がよいと思います。

受験の動機と、受験前のスペック

動機

動機は3つあります。

事前に参加したGoogle Cloud Next Tokyo 2026で刺激を受けた
同イベントで、受験料が$100引きになるクーポンをもらえた
ちょうど夏休みがあり、勉強する期間を確保できた

数ある認定資格の中でPCAを選んだのは、Google Cloudを俯瞰して勉強できそうだったからです。特定のサービスに閉じた資格ではなく、Compute / Storage / Networking / Database / Security / 運用あたりまで広く出題されるので、全体像を掴むのに向いていそうだなと。また、Professional資格ということもあり、現状の実力の証明にもなりそうだと思いました。

受験前のスペック

Google Cloudや他のパブリッククラウドの実務経験はなし（PoCでの経験はあり）
Kubernetesの認定資格は保有（CKA / CKAD / CKS）
Web系企業での、クラウドネイティブ領域のアーキテクトとしての経験が7年程度

先に書いた通り、公式が推奨している「Google Cloudを使用したソリューションの設計と管理の経験1年以上を含む、業界経験3年以上」は満たしていません。

ただ、受けてみた感想としては、Kubernetesやクラウドネイティブ全般、インフラ一般の知識はかなりそのまま通用しました。試験にはGoogle Cloud固有のサービスを選ばせる問題だけでなく、マイクロサービスやコンテナ、ネットワークの一般的な設計の問題も出てくるので、その部分は既存の知識で解けました。

逆に言うと、自分に足りていなかったのはGoogle Cloud固有の知識（サービス名とその概要等）で、ほぼそれだけでした。なので、対策もそこに集中させました。

試験対策としてやったこととその時期

期間としては約1ヶ月、実際の勉強時間は30時間程度です。

8月頭: とりあえず申し込み

先に受験を申し込んで、締切を作りました。9月は予定が多かったので、受験日にはちょうど空いていそうな8月最終週を選びました。試験は日本語と英語を選択できたので、日本語を選択しました。

盆休み: Udemyの講座を3日で1周

以下の講座を3日程度で1周して、概要を掴みました。

Google Cloud Professional Cloud Architect(PCA)の講座

久しぶりにペーパーテストの勉強をするので、少し違う勉強方法を試してみたいと思い、Obsidianを使って、講座で聞いた内容をチートシート的にまとめてみました（Obsidian自体は現状もメモツール兼個人用のナレッジベースとして使っています）。先にも書いた通り、この試験はサービス名とその概要がわからないと解けない問題が多いので、「サービス名 → 一行の説明」という形式でメモを取った上で、あとで何度か見直すようにしました。

動画を流し見するだけだとサービス名が定着しないので、結果的にはこのメモを作って見直す作業が対策の中心だったと思います。

8月3〜4週目: Udemyの模擬試験を1周

以下の模擬試験を1周しました。

Google Cloud Professional Cloud Architectの模擬試験

この時点で7~8割は取れていたので、実力を出せれば合格できそうな感じはしていました。間違えた問題については、その場で解説を読むだけでなく、先に作ったチートシートに書き戻すようにしつつ、講座の動画も見返すようにしました。

また、この時期にケーススタディの公式ドキュメントにも目を通しておきました。そんなに長くないので一読しておくとよいかと思います。

使わなかったもの

公式ドキュメントやCloud Skills Boostなどは、ほぼ読んでいません。結果的にはUdemyの講座と模擬試験の2つだけで足りました。

ただしこれは「試験に合格する」ことに最適化した話で、実際にGoogle Cloudを使えるようになるためには別の学習が必要だと思っています（このあたりはまとめに書きます）。

暗記用に作ったチートシート

自分が作ったメモをほぼそのまま載せておきます（フォーマットは直しています）。公開にあたって、現行のサービス名や仕様を確認して修正しています（一応、内容はブログ執筆時に検証していますが、誤りが含まれる可能性もあるので、公式ドキュメントを確認してください）。

基礎

リージョン: 地理的な単位
ゾーン: リージョン内の独立した障害ドメイン
グローバルリソース: リージョンやゾーンに依存しないリソース

管理

リソース階層: Organization → Folder → Project → Resource
Organization Policy: 組織内に適用される制約。IAMによる権限付与とは別レイヤなので、IAMで許可されていても制約側が優先される
Cloud Billing: 料金管理。BigQueryへのエクスポートが可能
プリンシパル: ユーザ、グループ、サービスアカウントなど、権限を付与される主体

Observability

Cloud Logging: ロギング
- ログバケット: _Default は保持期間30日、_Required は400日（変更不可）
- ログルーター: ログの転送設定
- シンク: ログの宛先
Log Analytics: Cloud LoggingのログをSQLでクエリできる機能
Cloud Monitoring: モニタリング
Cloud Audit Logs: 監査ログ
Ops Agent: VMに入れるエージェント。Cloud Monitoringでより詳細な情報が取れるようになる
Cloud Trace: トレーシング
Cloud Profiler: アプリケーションコードのプロファイリング（CPU / メモリの使用量）
Error Reporting: エラーログの集約と解析
Google Cloud Managed Service for Prometheus (GMP): マネージドなPrometheus

セキュリティ

IAM: リソースに対するアクセス制御。RBACと、IAM Conditionsによる属性ベースの制御に対応
- 基本ロール: roles/viewer、roles/editor、roles/owner など。粒度が粗く、利用は非推奨
- 事前定義ロール: roles/bigquery.dataViewer など。原則こちらを使う
- カスタムロール: 既存の権限を組み合わせて作るユーザ定義のロール
IAM Conditions: 時刻やリソース属性などに基づいてアクセスを制限する、条件付きロールバインディングの仕組み
Cloud Identity: IDaaS。Google WorkspaceやオンプレのActive Directoryと連携してID管理を行い、IAM（認可）の認証基盤となる
Google Cloud Directory Sync (GCDS): オンプレのActive Directory / LDAPからCloud Identityへ、ユーザやグループを同期するツール
Managed Service for Microsoft Active Directory: マネージドなActive Directory
Access Context Manager (ACM): リクエストのコンテキスト（誰が、いつ、どこから、どのデバイスでアクセスしたか）に基づいてアクセスを許可・拒否する
Identity-Aware Proxy (IAP): ACMのコンテキストとユーザIDでアクセスを認可する
Sensitive Data Protection: 機密情報の発見・分類・保護（マスキング、トークナイゼーション）。Cloud DLPと呼ばれていたもの
Cloud KMS: 暗号鍵の管理。ローテーションにも対応
- Google管理の鍵: デフォルト
- CMEK: 顧客管理の鍵。Cloud KMS上で顧客が管理する
- CSEK: 顧客提供の鍵。鍵素材をリクエストごとに顧客が渡し、Cloud KMSには保存されない
- Cloud EKM: 外部の鍵管理システムにある鍵を、Cloud KMS経由で参照する
- Cloud HSM: ハードウェアセキュリティモジュール内で鍵を生成・管理する
Assured Workloads: データが指定した地域でのみ保存・処理されることを保証する（データレジデンシー、主権要件への対応）
VPCファイアウォールルール: Priorityの数字が小さいほど優先度が高い（暗黙のルールは65535）

Compute Engine

OS Login: IAMを使ってVMにログインする仕組み
マシンタイプ: n2-highmem-2 のような命名で、末尾の数字はvCPU数
ディスク: Persistent Disk、Hyperdisk（次世代）、Local SSD（一時的な用途にのみ使える）
Spot VM: 低価格のVM。強制終了（プリエンプション）される可能性があるので、バッチ処理などに使う
ラベル: 課金・コスト管理用に割り当てるキーバリュー
ネットワークタグ: ファイアウォールルールやルートの適用対象を指定するためのタグ
タグ（セキュアタグ）: Resource Managerのタグ。IAM Conditionsやファイアウォールポリシーの条件に使える
メタデータ: 起動スクリプトや環境変数的な値をインスタンスに渡す仕組み
Node Affinity Label: 作成されるインスタンスを特定のノードに固定するためのラベル
Sole-tenantノード: 単一の分離された物理サーバ上でVMを実行できる
VM Manager: VMの設定とポリシーの管理。OSの初期設定やパッチ適用など
Batch: マネージドなバッチ処理のスケジューラ
インスタンステンプレート: VMの設計図。MIGの作成に使う。イミュータブルなので編集できない
マネージドインスタンスグループ（MIG）: VMのグループ。自動スケール、ヘルスチェック、自動修復に対応
Backup and DR Service: バックアップとDR
リフト＆シフト: アプリケーションをほとんど変更せずにそのままクラウドへ移行する手法
Migrate to Virtual Machines: VMwareなどのソース環境からCompute Engineへ、エージェントレスでVMを移行する。Migrate for Compute Engineと呼ばれていたもの
継続利用割引 (sustained use discounts): 事前契約なしで、1か月に長く稼働したリソースへ自動適用される割引
確約利用割引 (committed use discounts): 一定量の利用を1〜3年など期間確約する代わりに、大きく割り引かれる仕組み

GKE

Autopilotモード: ワーカーノードもGoogle Cloud側が管理する（コントロールプレーンは標準モードでもGoogle Cloud管理）
Fleet: 複数クラスタを論理的にグループ化したもの
マルチクラウドクラスタ: 他のクラウド上のクラスタも管理対象にできる
Cluster Autoscaler (CA): ノードの自動スケール
Cloud Service Mesh: Istioのマネージドサービス
Config Sync: Fleet内のクラスタ間での設定の同期
Policy Controller: OPA Gatekeeperベースのポリシーをクラスタやフリートに適用する。強制（Enforce）モードと監査（Audit。実際には禁止せず監査ログのみ出す）モードがある
コントロールプレーン承認済みネットワーク: コントロールプレーンへのアクセスをCIDR単位で制限する。Master Authorized Networksと呼ばれていたもの
限定公開クラスタ（Private Cluster）: ノードやコントロールプレーンに内部IPアドレスのみを用い、外部からのアクセスを制限するクラスタ

App Engine

スタンダード環境: フルマネージド
フレキシブル環境: Compute Engine上でカスタムコンテナを実行できる。カスタムVPC内でも動作させられるが、最小インスタンス数をゼロにできない
トラフィック分割により、Blue/Greenデプロイメントやカナリアリリースに対応

Cloud Run

Cloud Run Service: 通常のワークロード。Revision（コンテナと設定のスナップショット）を持ち、これらの間でトラフィックを分割することで、カナリアリリースやBlue/Green、自動スケールに対応する
Cloud Run Job: バッチ
Cloud Run functions: FaaS。Cloud Functionsと呼ばれていたもの
Serverless VPC Access: Cloud Runからユーザ定義のVPC（Compute Engine、Cloud SQLなど）にアクセスする。中継用のConnectorが必要
Direct VPC Egress: 同じくVPCへのアクセスに使うが、Connectorが不要

ストレージ

Cloud Storage: オブジェクトストレージ
- ストレージクラス: Standard、Nearline（月1回程度のアクセスを想定）、Coldline（四半期に1回程度）、Archive
- Autoclass: ライフサイクル管理を書かなくても、アクセス頻度に応じて自動でクラスを移行してくれる機能
- 署名付きURL: 特定期間のみのデータ公開
- 均一なバケットレベルのアクセス: ACLを無効化し、IAMのみでアクセス管理する（対になるのがきめ細かい制御モード）
Persistent Disk / Hyperdisk: ブロックストレージ
Filestore: ファイルストレージ / NAS
Storage Transfer Service: 大規模なデータ転送
Transfer Appliance: アプライアンス製品にデータを取り込んでから、Googleのデータセンターに物理的に送る。大量データのオフライン転送に用いる
Cloud Storage FUSE (gcsfuse): バケットをローカルファイルシステムとしてマウントする仕組み

ネットワーク

VPC（リージョンによらない） → サブネット（リージョンごと）
VPC Peering: VPC間の通信。双方のVPCでそれぞれピアリングを作成して初めて有効になる。IPアドレス範囲が重複してはいけない。また推移的ではない（A-B、B-Cで設定されていても、A-Cは通信できない）
共有VPC: 組織内、プロジェクト間でのVPCの共有
VPC Service Controls: マネージドサービスに対するネットワークレベルのアクセス制御。サービス境界を指定し、そこを越えるアクセスを制御する。Access Context Managerと組み合わせると、アイデンティティやデバイスベースの制御もできる
Private Google Access: 外部IPアドレスを持たないリソースから、内部IPアドレスのままGoogleのサービスにアクセスさせる
Cloud VPN: VPCと外部のネットワークをVPNで接続する
Cloud Interconnect: VPCと外部のネットワークを専用線で接続する
- Dedicated Interconnect: 10Gbps / 100Gbps。冗長構成を組んだ場合のSLAが99.99%（単一構成では99.9%）
- Partner Interconnect: パートナー経由の接続。より小さい帯域から選べる
Direct Peering: Googleのエッジネットワークとピアリングする接続。帯域幅を保証するSLAはない
Network Connectivity Center (NCC): 複数のネットワークをハブに統合して管理する
Cloud NGFW: ファイアウォール
Cloud Armor: WAFとDDoS保護。主にロードバランサ周辺の保護が目的
Cloud IDS: マネージドなIDS
Cloud Router: マネージドなBGP
Cloud NAT: マネージドなNAT。外部IPアドレスを持たないリソースが外部ネットワークにアクセスするための方法。Cloud Routerに設定をアタッチする
Cloud Load Balancing: ロードバランサ。バックエンドにCloud Storageを直接紐づけることもできる。ヘルスチェックは 130.211.0.0/22 と 35.191.0.0/16 から送信される
Cloud CDN: CDN。Cloud ArmorやCloud Load Balancingと組み合わせて使う
Cloud DNS: DNS。ルーティングポリシーの設定により、地域や重みに基づいた振り分けもできる

データベース

Cloud SQL: マネージドだが、一般的なRDBMS（MySQL / PostgreSQL / SQL Server）をホストする。Auth Proxyを使うことで外部IPが不要になる
- SQL Insights: クエリのパフォーマンス分析
AlloyDB: マネージドなPostgreSQL互換DB
Spanner: NewSQL（外部整合性）
Bigtable: マネージドなワイドカラム型のNoSQL DB。行キーに紐づく複数の（列ID, 値）の組を持つ。近い行キーが近いノードに乗るため、行キーの設計が重要。ミリ秒単位のレイテンシで、数百万/秒の読み書きができる
Firestore: NoSQLのドキュメントデータベース。Firestore本来のネイティブモードと、Datastore APIとの互換のためのDatastoreモードがある
Datastream: フルマネージドなCDC（変更データキャプチャ）サービス

データ分析

BigQuery: データウェアハウス。列指向で、ペタバイト級のデータ分析ができる。dataset → table という構造
- jobUser ロール: クエリの実行権限。データの閲覧権限を明示的に含まないことに注意
- dataViewer ロール: データの閲覧権限
Dataproc: マネージドなHadoop / Spark / Hive / HBase / Presto
Pub/Sub: メッセージキューイング。Topic（グローバルリソース）、Publisher、Subscriber。デッドレタートピック（配信の再試行回数が上限に達したメッセージの転送先）に対応
Dataflow: 大規模データの分散処理（Apache Beam）
Managed Service for Apache Airflow: Airflowのマネージドサービス。Cloud Composerと呼ばれていたもの
Dataprep: データラングリング（前処理）

DevOps

Cloud Build: マネージドなビルド環境
Artifact Registry: コンテナイメージとビルド成果物のレジストリ
Binary Authorization: GKEやCloud Runへのデプロイ時に、承認されたパイプラインでビルド・署名されたイメージのみを許可するポリシーを強制する
Cloud Deploy: マネージドなデプロイサービス

IaC

Terraform: HashiCorp製のIaCツール
Infrastructure Manager: マネージドなTerraform
Deployment Manager: YAMLベースの構成管理ツール。サポート終了済みで、Infrastructure Managerへの移行が推奨されている

移行

Migration Center: 移行手法の評価
7R
- Retain: 維持
- Retire: 廃止
- Rehost: Migrate to Virtual Machines
- Relocate: Google Cloud VMware Engine
- Replatform: Database Migration Serviceなど
- Repurchase: SaaSへの置き換え（Lookerの導入など）
- Refactor: Google Cloudのマネージドサービスを使う形に作り替える

連携

API Gateway: APIゲートウェイ
Apigee: API管理プラットフォーム
Application Integration: iPaaS。他社SaaSとGoogle Cloudを接続するフルマネージドサービス

AI

Gemini Enterprise Agent Platform: AIプラットフォーム。Vertex AIと呼ばれていたもの

結果

結果は合格でした。

当日の流れは以下の通りです。

午後休を取って、近くのテストセンターへ
マイナンバーカードで本人確認をして、持ち物をロッカーに預け、コンピュータのある試験室へ
2時間の試験で、10分ほど余ったので、問題の見直しに充てた
試験終了後、すぐに画面上で結果が表示される

体感の難易度としては、模擬試験がちゃんと解けていれば問題ないレベルでした。逆に言えば、模試の正答率がそのまま合否の先行指標になるので、直前の判断材料としても使えると思います。

まとめ

取ってよかった点は以下です。

Google Cloudとそのサービスの概要について、満遍なく学ぶにはちょうどよい試験でした。実務で触っていないサービスも含めて、名前と用途が一通り頭に入ったので、設計の場で選択肢として出せるようになりました
Google Cloudだけでなく、マイクロサービスやクラウドネイティブ全般、インフラについての問題も出てくるので、基礎の復習にもなりました

一方で、期待と違った点もあります。

各サービスの細かい設定については出てこないので、実際に使えるようになりたい場合は、別に学習する必要があります。この資格を取ったからといってGoogle Cloudが使えるようになるわけではないです

簡単な試験ではないですが、受ける価値はある試験だと思います。Google Cloudの全体像を短期間で掴みたい人にはおすすめできます。

認定の有効期間は2年間です。更新試験は1時間・25問・$100（英語試験のみらしい）で、ケーススタディ関連の問題が全体の90〜100%を占め、しかもそのケーススタディは生成AIソリューションの活用が題材になっているとのことなので、また2年後に何か書くかもしれません。

参考リンク

2025-12-24

負荷試験とパフォーマンスチューニングについてまとめてみた

最近パフォーマンスチューニングについて興味が出てきて、いろいろ調べています。やればやるほど知識が得られて結構好きです。AIにも簡単には奪われませんしね笑

ちょうどアドベントカレンダーの時期だったので、こんな記事を書いてみました。

qiita.com

もしよければご覧ください。（今年もブログの更新あまりできなかったなぁ。。。）

2025-02-18

最近やってる仕事まとめ

3年も空いてしまいました。ここまで来るとなにも思わないですね。。今後は（も）、なんか思いついたら更新する感じにしようかなと。

2年ほど前に管理職になり、いろいろやってます。最近自分がやってることってなんだろ、ってのをまとめたので、メモ代わりにここにも転記しておこうかなと。

前提

自社Webサービス（決済系）運営
約20人を管理（正社員・非正規社員含む）する中間管理職

やってる仕事

サービス運営

※プロジェクト管理（スケジュールのレビューやスクラム運営）
※プロダクト管理（ざっくりやること出し。新規開発案件、メンテ案件、セキュリティ対策（脆弱性対応、インフラ更新への対応等）などの優先度付けと品質管理）
リリースのレビュー（リリーススコープ、QAカバレッジ、オペレーション手順書、リスク/イシューの確認）、その他変更管理（依存先の変更も含む）
障害対応（特に影響範囲が大きいものは他部署との連携など）
情報セキュリティまわりの管理、各種監査対応
メンバーへのシステム権限承認
新規サービス等についての助言、技術まわりの提言など

エンジニアとしてのタスク

システムアーキテクチャ作成、レビュー
技術タスクのブレークダウン（さっくりした要件を、ジュニアエンジニアでもわかるレベルのタスクに落とす。あるいはシニアエンジニアが落とす手伝いをする）
技術上の決定（揉めたり決められなかったりした場合）
技術上の助言（アイデア出し、ブロッカーの特定と排除など）
※設計、コード、手順書レビュー
※テストケース、観点レビュー

組織運営

☆組織戦略策定、周知
☆リソース・アサイン管理
上のマネージャへの定期報告
チームリーダーからの定期報告を聞く
他部署、外部ベンダとの定例、課題出し
外部ベンダ、クラウドサービスへの受発注・検収
勤怠管理
☆予算管理（工数、ソフトウェアライセンス等含む）
KPI管理
改善系の議論（生産性、品質向上、モチベーション管理）

採用

☆CVチェック、面接
オンボーディング、オフボーディング
人事/派遣エージェントとのミーティング
派遣社員管理（契約継続、社員化支援等）

人材育成

☆目標設定・評価面談
☆査定
メンバーとの1 on 1

☆がついているものは特に重要だと考えているもの、※がついているものは他の人にうまく投げたいなと思っているものです。

こう見ると結構ありますね。私の役割は単なるEMだけでなく、組織運営者としての管理職の役割もあるので、こんな感じになっています。

そういう意味だと、サービス運営、エンジニアタスクと、組織運営・採用・人材育成のあたりである程度線を引けると思っていて、今後はどちらか片方（個人的には前者）を他の人に移譲していければいいのかなと…みたいなことを考えています。

2021-04-11

チームでコードレビューをしているときに考えていること

この記事はなに？

最近、自分の経験や考えていることを言語化してみる実験をしています。自分で言語化したことのある概念については自信を持って他の人に話せるし、一般化して横展開していくことも可能になるので、メリットが大きいのかなと。

第一弾として、私がテックリードとしてチーム内でコードレビューをしている際に考えていることをまとめてみました。

注意点

思いついたら随時更新します
今回の話のターゲットは主にWebフロントエンド/バックエンドのアプリですが、その他の開発にも使えるノウハウはあると思います
ここで書いているのは、仕事でチームを組んだ際にピアレビューをする際の話です。OSS等のコードレビューとは違いがあるかもしれないです

TL; DR

十分な事前準備をすることでレビューの手間を減らそう
目的にフォーカスすることで本質的で建設的なレビューをしよう
コードレビューを通してレビュワー、レビュイーともにもっと議論しよう

プルリクエストを出す前にやっておきたいこと（コードレビューで見たくないこと）

以下については、PRを出す前にやっておくべき。

コードレビューの目的と期待値についての認識合わせ

これが一番大事。

これはすべての「作業指示」に共通することだが、いちばん大事なのは指示者（この場合はレビュワー）と作業者（この場合はレビュイー）で事前に作業の目的とその期待値を揃えておくこと。これが十分でないとあとで揉める原因になるが、意外とできていない場合が多い。

少なくとも、

レビューの対象になる機能/バグ対応
何が完了した時点で、どの点をレビューするか/レビュー依頼するか？
どれぐらいの変更が入り、それにどれぐらい工数がかかりそうか

あたりについては事前に握っておく。時間があればissueチケットにまとめておけばいいし、なければチャット等に残しておくとよい（口約束だけだと忘れられやすい）。

ここで、PRの規模が大きくなりすぎないように注意する。

一般に、レビューするコードの行数/範囲が大きくなるとレビュワーもレビュイーもしんどい（イメージとしてはコードの行数に対して指数関数的につらくなる）。基本的にPRの単位はひとつのフィーチャーを対象とし、それでもフィーチャーが大きすぎる場合は、小さなフィーチャーに分割できないかを考える。一概には言えないが、変更されるコードが本番コード/テストコード含め800行、ファイル数で30を超えると分割の目安になる（リファクタリングとかでない限りこんなに大きくなることはほぼない）。

例：
X機能の実装（UIデザインのみ）のレビュー。ビジネスロジックと単体テストは範囲に含まず、正常系のUIデザインのみをレビューのターゲットとする。
変更するクラスはXComponentとYService。
1日あたり3.5時間（約50%）の稼働を想定して、初回レビューまで2人日程度を見込む。

また、可能なら、コードレビューで見るべき/見るべきでない点についてのガイドラインを作って先に共有しておくとよい。このブログ記事も半分ぐらいはそれを意図している。

設計/修正方針に関する打ち合わせ

上とは別に、時間があればおおまかに設計/修正の方針について認識を合わせておくとよい。

UIデザイン
APIインタフェースデザイン
クラス設計
ディレクトリ構成

あたりを握っておく。

CIを通す

コードレビューを持続可能な仕組みにするために、レビュワーの負担はできるだけ減らしたい。人間が見る必要のないもの（見るべきではないもの）については、自動化された仕組みで拾えるようにしておく。

コードフォーマットが正しいか？

Linter/フォーマッタにかける。フォーマットに違反している場合、PRを出した時かビルド時にCIで落とす
コードの複雑度と臭い

静的コード解析にかける。ある程度の基準を設けて開発者間で合意し、それを下回るものはCIで落とす。もちろん、静的解析だけでは全部拾いきれないので、漏れた部分はレビューの対象に回す
単体テスト

これも、どのクラスを対象としてどの程度のカバレッジの単体テストを行うかの基準を設けて合意し、それを下回るものはCIで落とす。カバレッジ基準については、むやみに高くしすぎるとコードの質に寄与しないテストが増えてしまうことがあるため、うまい落とし所を探るようにする

セルフレビュー

コードレビューをレビュワーに依頼する（= PRを出す）前に、レビュイー自身で自分が書いたコードをレビューするようにする。これは意外と重要で、実際にやってみると、これだけでもけっこう見落としや間違いが見つかる。

観点は以下のような感じ。

PRの形式が正しいか？

Issueチケットと紐付けられているか、PRを出すターゲットブランチが正しいか、ブランチ名やコミットがあらかじめ合意した形式に従っているか、diffは想定通りか、コンフリクトが起こっていないかなど、形式的にチェックできることについてはチェックし、問題がある場合は修正しておく。これらもCIに載せられそうならCIで落とすようにする。
コードが期待通り動くかどうか？

機能要件を満たさない、つまり「設計書通りに動かない」コードをレビューに出さない/出させない。当たり前のことのように思えるが、特に経験の少ないエンジニアがレビュイーになっている場合は、ケアレスミスや単純な見落としが多いので、基本的な挙動については必ずPR提出前に自分で確認させるようにする。前述した「レビューの目的と期待値」にもよるが、多くの場合、PRを出す時点では自動化された単体テストまで終了していると思う。ここでの「確認」は正常系のさっくりした挙動確認にとどめ、細かい部分はコードレビュー、スプリントレビュー、結合テスト、QA等で多角的に拾うとよい。
PRにおける議論の論点をまとめる

事前に、「コードを書いていて疑問に思ったこと」、「意見がほしいこと」、「やってもよさそうな気がするけどやらなかったこと」、「やりたかったけどやれなかったこと」について、理由も含めてまとめておくと、PRにおいて議論しやすい。レビュワーに直接伝えてもいいし、PRのコメントとして記載してもよい。レビューは双方向の議論の場であることを意識し、積極的に意見を出していくと、理解が深まってレビューの価値が高まると思う。

その他、もちろん下記のレビュー観点についても、レビュイーの責任でセルフレビューし、必要があれば修正するかPRコメントに記載しておく。

コードレビューで見たいこと

自分がレビューをする時に気にしている観点をざっとまとめておく。まだ足りない点やまとめきれていない点があるので、見つけたら随時追加する。

PRの形式

Issueチケットとの紐付け
- あとでコミット履歴を見たときに変更理由が明確なようにしておく
ブランチ戦略との整合性
Descriptionの妥当性（事前に合意したことをやろうとしているか？）
コミットが適切か？
- コミットメッセージ、粒度は適切か？
コミットのコンフリクトがないか？

PR内の事前質問についての回答

レビュイーから質問や意見を求めるコメントがあれば、それに回答する。再レビューの場合は、以前に行った指摘が意図通りに解決されているかについても確認する。

機能要件を満たしているか

前述の通り、ここはレビュイーによるセルフレビューにより解決できていることを期待したいが、設計についての認識違いや実装の瑕疵など、拾えそうなものについては拾う。一行一行見ていくと時間がかかるため、実際に開発環境等で動作させてチェックするとよい。

非機能要件を満たしているか

上述の通り、コードレビューでは、主に非機能要件についてのレビューを中心にしたい。

以下、思いつく限りの観点を箇条書きで書いていく。

非機能要件については、IPAの非機能要求グレードを参考にしている。

www.ipa.go.jp

可用性について

エッジケースを適切にハンドリングできているか？
- null値/空文字/空集合/デフォルト値
- 境界値（0、負数、intの最大値とそれより大きい数など）
- 型変換（intの変数に文字列を入れたときどうなるか？）
- ネットワークエラー/IOエラー/DBエラー
- 非同期処理によるエラー（排他制御のミス、デッドロックなど）

パフォーマンス（性能・拡張性）について

（動作はするが）現実的でない実行時間（≒ループ回数）になっていないか？
- 例えば、通常のプログラミング言語で $10^{9}$ 回以上ループが走ると、実行に10秒以上かかる可能性が高く、Web APIであればほとんどの場合非機能要件を満たせない
適切なアルゴリズムとデータ構造が使われているか？
- 例えば、HashMapを使えばO(1)で検索できるところをArrayListで検索していないか？
- もちろん拡張性とのトレードオフはあるので、場合によっては遅い方を選ぶこともある
現実的でない量のメモリを確保する実装になっていないか？
現実的でない量のスレッドを作成する実装になっていないか？
スレッドセーフか？
利用したメモリをアプリのライフサイクルの中ですべて回収しているか？メモリリークしていないか？
アプリが吐き出すログやその他のファイルの分量は適切か？ログ溢れが起こらないか？
DBへのコミットの単位は適切か？
- 特にバッチ/ワーカーアプリにおける逐次コミットは遅さの原因になることが多い。バルクアップデートの手段がないか検討すること

可読性（運用・保守性）について

クラス/メソッド設計
- 単一責任の原則（SRP）を満たしているか？神クラスになっていないか？
- DRYを満たしているか？まったく同じことを実現しようとしているのにクラス、メソッド等を分けていないか？
- クラス/メソッド/変数のスコープは妥当か？
  - 例えば、ローカル変数で十分なことをインスタンス変数で行っていないか？
- 1メソッドで実行しようとしていることが大きくなりすぎていないか？
  - 特に、メソッドの行数が多すぎたり（1メソッド50行以上とか）、メソッド内の条件分岐が多くなりすぎたり（ネストが3階層以上とか）していないか？
コーディング規約
- クラス/メソッド/変数の命名は妥当か？
  - 命名はコーディング規約に沿ったものか？
  - 名前が体を表しているか？
- コードコメントは適切な内容か？
  - コードを読むだけでは意図のわかりづらい箇所にコードコメントを入れてあるか？
    - 特に、暫定対応をした箇所には対応するチケット番号を書いておくとよい
  - コードコメントの量は必要十分か？また、内容が陳腐化していないか？
    - "How"（どのように実現するか？）ではなく"Why"（なぜこの実装になっているか？）や"Why not"（なぜ他の実装になっていないか？）をソースコードにコメントするようにする。Howはソースコードを読めばすぐにわかり、かつ頻繁に陳腐化するのに対し、他はコードに残らない重要な情報になることが多いため。
    - 不要なコードコメントは減らし、できるだけクラス/メソッド/変数名に伝えたい情報を詰め込むようにする
    - コードに残す必要のない、議論の過程などについてはコードコメントではなくPRコメントに残すようにする
ログ
- ログレベルは適切か？
- ログ文言は事象を表すわかりやすいものになっているか？エラーログの場合、エラーが発生した場所と時間、原因がログから追跡できるようになっているか？
テスタビリティ
- メソッドが不要な副作用を持っていないか？
- イミュータブルな変数/メソッドを利用しているか？
- ユーザからの入力値や現在時刻、ランダム値など、自動テストの実施において障害になる値を外部化できているか？
自動テスト
- 単体テストが十分にロジックを網羅しているか？
  - 行カバレッジの網羅だけでなく、通常の使用に即したユースケースやエッジケースを網羅できているか？
- タイミングによってテストが通ったり落ちたりするようなつくりになっていないか？
  - 特に、非同期処理や時刻（現在時刻、月末、うるう年、タイムゾーンなど）の扱いが正確にできているか？
- 単体テストの量は必要十分か？
  - テストケースとして重複しているテストや、コードの質に寄与しないテストがないか？
設定、環境構築
- 容易にアプリのビルド/動作確認ができるようになっているか？複雑な手順が必要になってしまっていないか？
- 設定値の必要十分な外部化ができているか？
  - ステージング環境がある場合、容易に設定をステージング環境向けに切り替えられるか？

移行性について

捨てやすいコードになっているか？
- 例えば、Web APIにおけるコントローラ、Webフロントシステムにおけるコンポーネントなどが、今後の運用の中で通常の使用に即した分割になっており、不要になったり、システム分割したりする際に容易になっているか？
リリース後に問題が発生した場合、ロールバックが可能な実装になっているか？
後方互換性が必要な場合、それを担保できているか？
- 旧バージョンを廃棄することが決まった場合、容易に可能か？

セキュリティについて

最新版のプログラミング言語/フレームワーク/ライブラリを使っているか？
- 改修の場合は、影響範囲を見ながらバージョンアップするか都度判断する
ミドルウェアのユーザ名/パスワードにデフォルト値や安易な値を使っていないか？
入力値のバリデーションが十分であるか？
（特に通信がインターネットを介す場合、）安全な通信を利用しているか？
クレデンシャル（パスワードや秘密鍵等）が外部に露出していないか？
- クレデンシャルについては、可能なら設計時に別リポジトリで管理し、アプリ実行時に値を注入するようにする
技術詳細など、ユーザにとって不必要な情報を外部に露出していないか？
- レスポンスとして返すエラーメッセージにスタックトレースやエラー詳細を含まない
典型的な攻撃（DoS/XSS/CSRF/SQLインジェクション/コマンドインジェクション/ディレクトリトラバーサルなど）に対処できる形になっているか？

設計指針に合致した変更か？

プロジェクトとして文書化された設計指針があるのであれば、それに従っているかもここで見る。なければ、テックリードの責任で変更がコードベース内での一貫性を保っているかを確かめる。

必要十分な変更か？

「PRの目的を達成するために必要な変更は余さず入れる」、「PRの目的を達成するために不要な変更は何も入れない」という観点も重要。

例えば、

動作させるのに必要な設定変更がコミットから漏れていないか？
- 例1：NPMのpackage-lock.json
- 例2：バージョンを上げるために必要なファイル（AndroidManifest.xmlのversionCode）
余計なファイル/クラス/メソッド/変数/ログ等が含まれていないか？
ファイルの実行権限等が必要十分か？

など。

特に、既存のコードを変更/削除するPRの場合は、他に変更漏れ/消し忘れがないか気をつける。レビューツールには変更のあるファイルのdiffしか出てこないので、これはコードレビューの観点として忘れずやった方がよい。

また、PRの目的に合致しないが有用と思われるリファクタについては、面倒でも新しくPRを作って入れてもらうようにする。

プルリクエストを承認する前にやっておきたいこと

テックリードとしてPRを承認し、マージする際には、以下を確認しておくとよいと思う。

指摘対応がすべて終了しているかを確認する
レビューの結果見つかった残作業やさらなる改善点がある場合は、レビュイーと話した上で、必要であればチケット化しておく
議論の記録がたどれるようにしておく
- 議論の結果決まったことがあれば、issueチケットかPRのどちらかに記載しておく

その他気をつけたいこと

その他、レビューをしていく中で培った私見をざっとまとめておく。

目的に沿ったレビューをする

自分自身、意外とやってしまうのは、PRの目的にそぐわない指摘をしてしまうこと。あまり関係ない指摘を続けてしまうと、それがある種の正論であったとしても、手戻りによる工数が膨らんだり、レビュイーを必要以上に混乱させることになる。事前に握った目的外の指摘は最小限に留めるようにする。

明らかにスケジュール内で実装不可能でありリリースのブロッカーにならないものについては、それを明記した上で「今後の課題」とする、あるいは別のチケットに切り出すことを考えるべき。実装のボリュームにもよるが、レビューの手戻りのピンポンが恒常的に3往復を超えていると、プロセスに何らかの問題がある可能性が高い。

レビューは双方向の議論の場

上でも述べたが、レビューは双方向の対等な議論の場であるという意識が必要だと思う。

ありがちなのは、コードレビューは開発プロセスに含まれているが、レビューが承認を取る/渡すための作業になってしまい、レビュワー、レビュイー双方の学びの機会が失われてしまうパターン。特にレビュワーとレビュイーにプログラマとしての実力差が大きい場合、レビュワーが一方的に指摘し、レビュイーは言われた点をひたすら修正するだけの作業になりやすい。

レビュイーは自分が書いたコードの意図や設計についての疑問、その他気になったことは何でも積極的にレビュワーに話すようにするとよいし、レビュワーの指摘が正しくないと感じたときは反論してよい。レビュワーは、コードレビューを自分が担当しているコードや周辺技術についての学習の機会、また、コードの質とチーム全体のスキルを上げていくための重要な工程だと認識し、レビューしていて気になったことについては調べ、思ったことを積極的に指摘するようにする。

指摘は論理的、客観的、具体的にする

コードレビューにおいて指摘をする際は、「論理が明快で、誰もが納得でき、何をどうすればよいかが明確になっている説明」をするようにする。言うのは非常に簡単だが、実行するのは簡単なことではないし、自分自身、完璧なアイデアがあるわけではない。

以下に自分がレビュワーとして試していることを記す。

「この方がキレイ」など、本人の主観によるような表現は避け、論理的な説明になるようにする。必ず指摘の理由を説明する
レビュイーの背景知識を考慮し、言葉遣いに反映する
- 特に、馴染みのない概念を説明する際には、具体的な例と、それをすることで何がいい/悪いのかを明示する
指摘の際、持論を補強するための参考文献を貼る
自分が少しでも理解できていない点があるのであれば、「指摘」ではなく「質問」の形式を取る。相手の意図を確かめた上で、自分の意見に反映する
修正方法が説明しづらいと感じた場合、指摘コメントの中に具体的なコードスニペットを書く
具体的な修正箇所を明示しておく
- レビューツールで該当箇所へのURLが取得できるなら、コメント内でリンクを張る
- 同一の指摘が複数箇所に当てはまる場合、「ここも同様です」を記載しておく
修正の必要がないものについては、「修正不要です」と明記しておく

お互いに理解し、理解されるような説明を心がける。

テキストコミュニケーションに頼りすぎない

レビューツールやチャットツールなど、テキストでのコミュニケーションは、非同期的に行うことができ、かつ記録が残るので非常に便利であるが、一方で難しさもあると感じている。

特に、

上で述べた通り、自分の指摘意図を完全に相手に伝えるのは概して難しい。特に非同期コミュニケーションの場合、相手が指摘を理解しているかどうかを確認する術がない。理解を誤っていた場合、その分はすべて手戻りになる可能性がある
意見が対立した際に加熱しやすい

などの問題がある。

結果的に5分話したら解決した、というケースも結構あったので、「うーん、伝わってないなー」と感じたら、面倒がらず相手と直接話した方がよい。ペアプログラミング、モブプログラミングのように、時間を取って一緒に画面を見ながら話すのも有効だと思う。

参考文献

開発現場に学ぶ、円滑なコードレビューに必要な8つの手法～手段から準備、実施時期まで徹底解説～ - エンジニアHub｜Webエンジニアのキャリアを考える！

www.jpcert.or.jp

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

作者:Dustin Boswell,Trevor Foucher
発売日: 2012/06/23
メディア: 単行本（ソフトカバー）

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

作者:ＲｏｂｅｒｔＣ．Ｍａｒｔｉｎ,角征典,高木正弘
発売日: 2018/08/01
メディア: Kindle版

2020-10-03

CKAD / CKAを受けてきた

勉強

例によって放置しまくってますが，あまり気にせず書きたいことを書くことにします．

タイトルの通り，今年の2月から9月にかけて，Certififed Kubernetes Application Developer（認定Kubernetesアプリケーション開発者．以下，「CKAD」），Certified Kubernetes Administrator（認定Kubernetes管理者．以下，「CKA」）を受けてきたので，何をやっていたかとちょっとした感想を残しておきます．

試験の概要

CKAD:

www.cncf.io

CKA:

www.cncf.io

どちらもCloud Native Computing Foundation（CNCF）が運営する，Kubernetesについてのスキルを認定する資格試験．実際にKubernetes クラスタを操作することで問題に回答する，ハンズオン形式であることが特徴．

CKADとCKAの違い

注意点として，2020年9月からCKAの出題形式（試験範囲，試験時間，問題数など）が大きく変わっていることに注意．古い記事に当たるときは気をつけること．

training.linuxfoundation.org

	CKAD	CKA
試験の目的	「Kubernetesを利用するアプリケーション開発者（クラスタ利用者）」としてのスキルを認定	「Kubernetesのクラスタ管理者」としてのスキルを認定
受験料	300USD*1	300USD
有効期限	受験日から3年間	受験日から3年間
試験時間	2時間	2時間
問題数	15-20問	15-20問
合格点	66%	66%
出題範囲	Core Concepts（13%） Configuration（18%） Multi-Container Pods（10%） Observability（18%） Pod Design（20%） Services & Networking（13%） State Persistence（8%）	Cluster Architecture, Installation & Configuration （25%） Workloads & Scheduling（15%） Services & Networking（20%） Storage（10%） Troubleshooting （30%）

最も大きな違いとして，CKADは，ほぼすべての問題が与えられたKubernetes上のリソースを閲覧/作成/変更することで解答できるものであるのに対し，CKAの試験範囲には，Kubernetesのアーキテクチャについての理解と，クラスタのインストール，アップグレード，トラブルシューティングなどのオペレーションも含まれる点が挙げられる．

個人的な所感として，CKADは一問一問の実装量がそれなりに多く，ちゃんと対策していかないととうてい時間が足りない．対して，CKAはカバーする範囲が広い分，ひとつひとつの問題は易しめ，といった感じ．

どちらから始めればよいか

「マネージドサービスのKubernetesを雰囲気で使ってきたけどそろそろ覚えたい」とか，「Kubernetesそんなに知らないけどこれからガッツリやっていきたい」のであれば，CKADから始めるのがよいかと思う． Kubernetesを利用する機会と運用する機会であれば，たぶん利用する機会の方が多いし，試験内容が「Kubernetesを利用してアプリを作る」ことにフォーカスしていることが理由だ．

逆に，「SREとしてKubernetesを運用できるようになりたい」とか，「Kubernetesのアーキテクチャについても知りたい」のであれば，CKAから始めることをおすすめする． Kubernetesはもともと複雑な分散システムなので，この試験だけでKubernetesのすべてがわかるわけではないが，これからどういう勉強をしていけばいいかの指針にはなると思う．

試験範囲はわりとかぶっているので，ある程度理解に自信があるのであれば，両方一気に受けてしまうのもよいと思う．

受験記的ななにか

受験前のスペック

以前からクラスタ利用者としてはKubernetesを使っていたが，当時はせいぜい，DeploymentとServiceを作るのと，デバッグが必要になったときkubectl execでコンテナにログインしてログを読むぐらいだった．デバッグに必要なコマンド（kubectl get / describeとか）は知っていたが，それ以外は全然．

2019年秋

8月からアサインされたプロジェクトでKubernetesやIstioに触れる機会ができ，そろそろ体系的に理解したいなぁと思っていた．

社内プライベートクラウドでKubernetesを管理している人たちとお酒を飲む機会があり，そこで，

「自分たちの部署に入るなら最低限CKAは取ってて欲しいよねー」

という話になった．

ちょうど今後何をしていくか悩んでいた時期だったこともあり，Kubernetesという技術自体に興味はあったので，「受けてみてもいいかなー」と思うようになった．

2020年1月

正月特有の謎のやる気のままCKADに申し込んだ．

たぶんこの時にはCKAも受けようと思っていたと思う．最初がCKAではなかったのは，両方チラッと比較した上で，CKADの方がすでに知っていることが多かったし，とりあえずちゃんとManifestが書けるようになりたかったから，だったかな．

ちなみに申し込んだのは日本版のCKAD-JP．試験としての違いはないが，日本語で試験監督が受けられる．

2020年2月

そのまま1ヶ月放置してしまったが，重い腰を上げて試験日を決めた（CKAD/CKAは申込日から1年間の間，試験日を自由に選べる．受験場所さえ自分で確保すればわりといつでも予約できるので，かえってモチベーションが上がらなかった）．

とりあえずいろいろググってみて，

Kubernetes Slack

の#ckad-exam-prepチャンネルでおすすめされていたUdemyの講座*2をやった．

www.udemy.com

この講座は，

動画の講義
実際にクラスタを使った理解度テスト
模擬試験

に分かれており，講義パートで覚えたことを理解度テストですぐに試せる構成になっているのが良い点．講師はインド人のようだが，英語の訛りもさほどきつくなく，非常に聞き取りやすかった（英語字幕もある）．

最終的に1週間ほどでこの講座を2週したが，試験対策としてはこれで十分だったと思っている．

その他には，

公式ドキュメントのブックマーク（後述）をしたり，

Kubernetes完全ガイド（当時は第1版）

Kubernetes完全ガイド第2版 impress top gearシリーズ

作者:青山真也
発売日: 2020/08/17
メディア: Kindle版

で知識を確認したり，

github.com

www.youtube.com

このあたりで試験範囲とTipsを確認したり，

界隈では有名なKubernetes the hard way（自動化ツールに頼らずVM上にKubernetes クラスタを構築するハンズオン）をやってみたりしていた．*3

github.com

試験対策はトータルで2週間ちょいだったと思う．

CKAD当日

CKAD/CKAはリモートで行う試験のため，受験者の責任で「片付いていて」「人の入ってこない」部屋を選んで，受験会場とする必要がある．試験のために自室を片付けるのは面倒だったので，休日の午前中を選んで会社の会議室を会場にした．

持ち物は，

パスポート（身分証明用）
MacBook Pro（Webカメラが付属しているのでわざわざ用意する必要がないのが便利）
キーボード（いつも使っているHHKB）
ディスプレイ（会社に転がっていたもの）

予定した時間の15分前ぐらいに試験用のポータルサイトが開くので，そこで待っていると監督者からチャットで指示が来る．パスポートをWebカメラで見せた後，不正防止のために会議室全体や机のまわりをWebカメラで写すように言われる（MacBookだとここがしんどい）．その後試験に関しての注意事項が伝えられたあとで，試験開始となる．

普通に時間が足りなくて，3問ぐらい一瞥もできなかった問題があったと思う．

あと，最初は試験問題の言語を日本語にしていたが，翻訳の質があまり良くなく，出題意図がわからなかったので，すぐに英語に変更した．ここは改善してもらえると嬉しい…

翌日，合格通知があった．得点は86%．

f:id:lethe2211:20201003195619p:plain

2020年4月

受かった直後はすぐにCKAも受けようと思っていたが，気づいたら1ヶ月経っていた（ちょうどこの頃仕事が忙しかったのもある）．

申し込む．

2020年8月

長過ぎた五月病（笑）から復帰したので受験日を決める．

ちょうど前述のカリキュラム変更があったこともあり，変更後の9月に受けることを決めた．

2020年9月

すでにCKADを取っていたこともあり，試験対策としては，

前述のKubernetes完全ガイドを副読本にしながら，

上記のUdemyの講義のCKA版

www.udemy.com

を2周したのと，

kubernetes.io

の内容を読んだことぐらいしかない．

特に，クラスタをインストール/アップグレード/トラブルシューティングするタイプの問題については，アーキテクチャを念頭に置きながら，動きを理解するために手順含め何回も試して覚えた．

トータルで1週間程度．

CKA当日

こちらも休日に会社の会議室で受けた．

試験のポータルサイトがアップグレードされていてUXが良くなっていた．試験全体の流れはCKADと同様．

試験慣れしていたこともあってか，終了20分前には完答できた．

こちらも，翌日に合格通知が来たが，得点は81%だった．

f:id:lethe2211:20201003195652p:plain

自分の感触的にはほぼ完答だと思っていたので，なんか問題文の誤読が多かったのかな… すこしもやもや．

Tips

以下，試験対策時，試験時に使えそうなTipsをまとめておく．基本的にCKAD/CKAに共通して使えると思われる．

１. aliasを登録する

試験の性質上，コマンドのタイプ数はどうしても多くなるので，（指を壊さないためにも）できるだけ減らしたい．毎回入力するコマンドについてはalias登録しておく癖をつけておくとよい．

$ alias k=kubectl

２. リソースのshort nameを覚えておく

Kubernetesの一部のリソースには，"short name"というものが定義されている．例えば，PersistentVolumeClaimのresource nameは"persistentvolumeclaims"，short nameは"pvc"であり，kubectlを使って取得する際には，

$ k get persistentvolumeclaims

$ k get pvc
  # こちらでも可

のようにできる．必須ではないが，タイプ数が減らせるなら減らした方がよい．

ちなみに，

$ k api-resource

で，各リソースの有効なshort nameを確認できる．

３. YAMLのテンプレートを作る

Kubernetesの魅力の1つは，YAMLファイルのManifestを使うことでInfrastructure as Codeを実現できることだが，この試験に関して言うと，毎回エディタでYAMLファイルを書いてkubectl apply -fしていると率直に時間が足りない．うまい時短の方法を考える必要がある．

ひとつの方法として，YAMLのテンプレートを作るコマンドを使うことができる．おそらくほとんどの受験者がこの方法を使っているとみられ，この試験の必勝法のようになっている．

例えば，testという名前の，nginxコンテナを持つPodを作る際には，

$ k run test --image=nginx --restart=Never --dry-run=client -o yaml > 01-pod.yaml
$ cat 01-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - image: nginx
    name: test
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}
$ k apply -f 01-pod.yaml

のようにすればよい．コマンドを覚える必要はあるが，これでかなり時短できる．

コマンドだけで望みのManifestが作れない場合は，テンプレートを作った後にエディタで編集するようにするとよい．

この方法は，DeploymentやServiceなど，主要なリソースについてはだいたい使える．リソースによって使うコマンドが微妙に違うので，kubectl run，kubectl createあたりのヘルプを確認するとよい．

４. kubectlの命令的コマンドを使う

３.に関連して，さらに時短したい場合は，kubectlの命令的（Imparative）コマンドを使うという手がある．

よく使っていたのは，

$ k edit svc mysvc
  # "mysvc"という名前のServiceを直接編集する

$ k set image deploy mydeploy nginx=nginx:1.9.1 --record
  # "mydeploy"という名前のDeploymentの，"nginx"という名前のコンテナイメージを"nginx:1.9.1"に差し替える．それを履歴に残す

$ k expose deploy mydeploy2 nginx --name=mysvc2 --type=ClusterIP --port=80 --target-port=8080
  # タイプClusterIPのService"mysvc2"を作成し，"mydeploy2"という名前のDeploymentが内包するPodのポート8080番を，"mysvc2"のポート番号80番で露出する

$ k label po mypod foo=bar
  # "mypod"という名前のPodにfoo=barというLabelを付与する

$ k taint no mynode foo=bar:NoSchedule
  # "mynode"という名前のNodeにfoo=bar:NoScheduleのTaintを付与する

こんな感じ（もっとあったかも）．全部覚えることは不要だが，覚えてちゃんと使えるようにしておけば有利にはなる．

５. kubernetes.ioをブックマークする

試験中には，試験用のWebアプリ以外にもう一つブラウザのタブを開くことができ，

と，これらの子ページの参照が可能．

特によく使うのは https://kubernetes.io/docs/ （Kubernetes公式ドキュメント）だが，毎回必要なページをサイト内検索しているとけっこう時間がかかる．ブラウザのブックマーク機能を使うことは許されているので，よく使いそうなものについては登録しておくとよい．

以下，自分が使ったものを雑に晒しておく．

kubectl Cheat Sheet | Kubernetes

Ingress | Kubernetes

Persistent Volumes | Kubernetes

Deployments | Kubernetes

ReplicaSet | Kubernetes

Configure a Pod to Use a ConfigMap | Kubernetes

Labels and Selectors | Kubernetes

Taints and Tolerations | Kubernetes

Assigning Pods to Nodes | Kubernetes

Managing Resources for Containers | Kubernetes

Configure a Security Context for a Pod or Container | Kubernetes

Network Policies | Kubernetes

Configure Liveness, Readiness and Startup Probes | Kubernetes

DaemonSet | Kubernetes

JSONPath Support | Kubernetes

Manage TLS Certificates in a Cluster | Kubernetes

Define Environment Variables for a Container | Kubernetes

Init Containers | Kubernetes

Installing kubeadm | Kubernetes

Upgrading kubeadm clusters | Kubernetes

Operating etcd clusters for Kubernetes | Kubernetes

Kubectl Reference Docs

リソースを作る際，kubectl create等で作れるリソースについてはコマンドで作り，PersistentVolume，PersistentVolumeClaim，Ingress，NetworkPolicy，CertificateSigningRequestなど，コマンドで作れないリソースについては，ドキュメントからのコピペで作れるようにしておくとよい．

６. kubectl explainを使う

Manifestを編集する必要がある問題が出された際に，どこにどのkey/valueを追加すべきかわからなくなることがよくある．こういう場合，ドキュメントを調べるより，kubectl explainを使う方が早く見つけられる場合が多い．

$ k explain po.spec.securityContext
  # Pod（"po"）のspec.securityContextについてのヘルプドキュメントを参照する

これにより，YAMLのどこにどういった型の値を入れれば望みの動作になるかがわかる．

これは普段の運用でも使えるコマンドだと思う．

７. エディタに慣れておく

kubectl edit等で起動するエディタはデフォルトでVimに設定されている． Vimに慣れておくか，

$ export KUBE_EDITOR="nano"

のようにしてエディタを変えておく．

８. 試験時は解いた問題のメモを取る

試験の各問題には傾斜された配点が付いており，難しい問題には多めの配点が付与されている．

試験中，試験用のWebアプリ内のエディタを使ってメモを取ることが許されているので，試験の最初に全問題の配点をメモし，配点の高い問題から取り組むようにした．加えて，すでに解いた問題をメモにマークしておいた．

結果的に，無駄な時間を使わずに済んだと思う．

９. Chromeの設定をしておく

試験時に使えるブラウザは，所定のChrome拡張をインストールしたChromeかChromiumのみ．他のブラウザを使っている人は動きに慣れておくとよい．

あと，意外とやってしまうのが，誤クリックやショートカットキーでブラウザを閉じてしまうこと．できれば不要なショートカットキーは無効化しておくとよい．

試験の流れや試験環境については，

docs.linuxfoundation.org

このあたりに詳しい記載があるので一読しておくとよい．

まとめ

CKAD/CKAともに，Kubernetesの基礎を体系的に理解したい人には非常に良い試験だと思う．特に，実際にkubectlや他のコマンドを使ってクラスタを操作する体験は，実際のプロジェクトでもかなり役立った．

反面，資格試験としてみると，2/3の得点が取れれば合格してしまうので，「技術力の証明」という観点からだとちょっとよくわからないなとは思った．逆に考えれば，もっと軽い気持ちで受けてみてもけっこう受かるのかもしれない（CKAD/CKAともに，不合格でも追加費用無しで1回再受験ができる）．

これにてKubernetesのチュートリアル終了！と思っていたが，今年の11月にCertified Kubernetes Security Specialist（認定Kubernetesセキュリティスペシャリスト．CKS）という新しいKubernetesの試験ができるらしい．

training.linuxfoundation.org

気分が乗ればこっちも受けてみたい，ような気もしないでもない．

*1:"CKAD coupons"とかでググると値引きのためのクーポンコードが見つかる（かも）

*2:いつもは\24,000とけっこうするが，Udemyはちょいちょい95％セールをやってるので，そのタイミングを狙ってみるとよい

*3:Kubernetes the hard way，やってみればわかるが，ちゃんと理解するためにはインフラの知識がかなり必要になる．いちおう手順を最初から最後まで流しはしたが，正直あんまり理解できていなかったと思う

2019-03-31

Web APIのログ設計についての私見

設計

かなり放置してしまいましたが，久しぶりに気分が乗ったのでブログを書いてみています．

最近は仕事でSpring Frameworkを使って何度かWeb APIを開発しているのですが，その度に毎回同じようなことを悩んでいる気がするので，次に開発する自分に向けて，ちょこちょここちらにまとめておこうと思います．

結構私見が混ざりそうなのでこちらのブログで．

今回はログについてです．

注意事項

対象は，DBや他のAPIと通信して結果を返すタイプの一般的なRESTful APIを想定しています．
業務領域はちょっとカッチリ目のWeb系です．
特定のWebフレームワークには依存しないように書いたつもりですが，見返してみると若干Spring Frameworkに寄ってるような気もします...

ログ設計の観点

そもそもですが，Web APIのログってどんなものがあればいいのでしょうか？

仕様面の観点としては，

障害発生時にできるだけ早く運用者に通知されるようになっているか？また，ログから障害の原因を追跡しやすいか？
APIクライアントからの問い合わせなど，日常運用に際して使いやすいか？もう少し具体的に言うと，そもそもログの中から問い合わせの対象となるリクエストを見つけやすいか？また，ログの内容から問い合わせを解決するための手がかりをつかみやすいか？
業務量（QPS）やリクエストの実行時間を把握しやすいか？
開発時に起こった問題の原因を追いやすいか？（要するにデバッグログ）
その他，開発者/運用者/ログ分析者が知っているとよい情報を適切なタイミングで表示しているか？

があるかなぁと思っています．

要するに，使いやすいログを設計しましょう，ということです．

また，性能面の観点としては，

ログの出力がAPIの性能に大きく影響しないか？
ログによってシステムの他の構成要素に影響がないか？

といったところも重要です．

何も考えずたくさん出してしまうとログ追跡も難しくなりますし，ログ出力そのものがAPIの負荷の原因になったり，ログを吐き出しすぎてディスク溢れを起こしてしまったりするケースもあります．

これらの観点を鑑みて，私は以下のようにログを設計しています．

ログ設計

ログ分割と各ログの役割

以下の4つのログをファイルの形でAPIサーバに配置しています．その後，fluentd等のログ集約ツールで適宜集約サーバに送信するようにしています．

（以下，ログレベルはSLF4Jのものを基準としています）

SLF4J

request.log

APIが受けたリクエストを記録するログ．

HTTPのリクエストパス，クエリ文字列，リクエストボディ，リクエストヘッダ（，クッキー），リクエスト元のIPアドレスを記録します．

特に，何らかのバグによって途中でレスポンスが返らないまま処理が終了してしまう場合も考えて，できるだけ早いタイミングでログを記録することが重要です．

ログレベルはINFO．

response.log

APIが返したレスポンスの内容と，リクエストの処理にかかった時間（経過時間）を記録するログ．

HTTPのステータスコード，レスポンスボディ，レスポンスヘッダ，経過時間を記録します．アクセス量の調査については，基本的にこのログを利用します．

加えて，

APIのID（呼ばれたAPIを一意に識別するID）
ユーザのID（あれば）
ユーザが認証済みかどうか（認証済みユーザにのみコンテンツを開示する場合など）
APIクライアントのID（あれば）

あたりを別に記録しておくと，ログ検索の際の利便性が上がると思います．

ログレベルはINFO．

application.log

APIの内部ロジックにて，開発/運用に必要な情報を記録するログ．

いわゆるアプリログ．

ログレベル	観点
TRACE	基本的に使用しない．開発時に本当に必要になったときのみ．
DEBUG	デバッグの際に必要な情報を記録する．DEBUGレベルのログは本番環境で出力することを想定しない．「開発/デバッグ時にはいつも必要になるが本番には出したくないログ」のみを残し，開発中にだけ必要だったものなどは本番投入前に消しておくようにするとよい．例えば，DBに接続する際の接続情報や，APIロジック内での処理件数，経過時間など．
INFO	本番運用に際して有用な情報を記録する．INFOレベル以上のログはすべて，本番環境で出力することを想定する．不要な情報はできるだけ削ぎ落とし，本当に必要な情報のみを出力するようにする．特に，毎リクエストごとに出力されるログについては吟味し，request.log/response.logに入れられないかを検討する．例えば，バックグラウンド処理が起動/停止したことを示す情報や，APIの設定項目が更新された際の通知など．
WARN	「即時の対応が必要ではないが，運用者にすぐに通知されるべき警告」を記録する．自動電話の対象とはしないが，メールやSlackなどのメッセージングツールなどで運用者がすぐに把握できるようにはしておく．例えば，APIが想定しない入力が受け付けた場合や，（マッシュアップのAPI等で）一部の外部APIの呼び出しがエラーを返した（がAPI全体には大きな影響がない）場合など．
ERROR	「運用の継続を阻害しており，即時の対応が必要なエラー」を記録する*1．エラーの詳細（例外のスタックトレースなど）がわかるようにしておく．アラートの対象であり，自動電話等で夜間帯でも即時対応できるようにしておく．例えば，APIの業務ロジックが想定しない例外を送出した場合や，メモリやディスクの枯渇によってAPI自体の状態が不安定になった場合など．

stdout.log

フレームワークが吐き出すログの内容をリダイレクトして記録するログ．

多くのWebフレームワークでは，フレームワーク側で実行した内容のログを標準出力に出力する設定になっていると思うので，それを記録しておきます．

ログレベルは出力したログに依存します．

気をつけるべきところ

ファイルフォーマット

プレーンテキストで記録してもいいのですが，一度集約サーバに送ってしまうと目視で確認する機会がほぼなくなってしまうので，プログラムで処理しやすい形式が良いかと思います．個人的にはJSON形式がおすすめです．

ちなみに，ロギングにLogbackを利用しているのであれば，logstash-logback-encoderを利用することで，いい感じ（Logstash形式）にフォーマットしてくれるので，ELKで扱いやすいです．

GitHub - logstash/logstash-logback-encoder: Logback encoder which creates JSON for use with Logstash

JSONを使う場合でも，例えば開発時には目視しやすい方が楽かと思うので，必要に応じてフォーマットを変更しやすいようにしておくとよいかと．

リクエストID

ログごとにファイルを分割すると問題になるのが，どのログがどのリクエストに紐付いているのかわからなくなる点です．例えば，request.logから同じリクエストに紐づくresponse.logを探すことができなくなります．このため，各ログには，リクエストごとに（ほぼ）*2一意になるIDを付与するようにしています．

ちなみに，ZipkinやJaegerなど，OpenTracing APIに対応するトレーサーを利用しているのであれば，IDとしてTrace IDの値を使うとよいかと思います．

時刻

ログの中でいちばん大事なのは，そのログを取った時刻の情報だと思います．もちろん要件次第だと思いますが，普通のAPIであれば，精度はmsecぐらいあれば十分かと思います．

時刻のフォーマットについては，ISO 8601の基本形式か拡張形式のどちらかを使っておけばいいと思います．

ISO 8601 - Wikipedia

私はよくuuuu-MM-dd'T'HH:mm:ssSSSXXX （E.g., 2018-10-27T22:17:35.213+09:00）のフォーマットを使っています．

ログローテーション

サーバのディスク容量には限りがあるので，ログがディスクを圧迫しないようにすることは重要です．多くのロギングライブラリには，日別や日時別でログファイルを分割して古いファイルを圧縮，削除するログローテーション機能があるので，それを使うとよいと思います．

忘れがちですが，ログが溢れないかどうか，開発時に負荷試験で調べておくことも重要です．

ある程度信頼性を犠牲にしていいなら，ファイルを介さず直接TCP等で集約サーバに送ってしまう，という手もあるかと思います*3．

リクエスト元のIPアドレス

リクエスト元のIPアドレスについては，（他にAPIクライアントを識別するための情報があれば必須ではないものの，）どのAPIクライアントのどのサーバがAPIを呼び出しているかを把握していると障害対応が楽になるため，できれば取得しておきたい情報です．

様々な取得の方法がありますが，APIクライアントと取り決められるなら取り決めた方法で，特にそういうものがないなら，

X-Forwarded-Forヘッダが存在する際は，その値を,（カンマとスペース1つ）で分割した際の最初の要素（ロードバランサやリバースプロキシを経由するなどしてIPアドレスの付け替えがあっても対応できるので*4） 2.X-Forwarded-Forヘッダが存在しない場合は，REMOTE_ADDR（前段の呼び出し元IPアドレス）

を取得するとよいかと思います．

X-Forwarded-For - Wikipedia