Atsushi2022の日記

データエンジニアリングに関連する記事を投稿してます

AZ-104 勉強メモ

契約形態

  • Azureダイレクト
  • Azure EA
  • Azureインオープン
  • CSP

複数サブスクリプションのメリット

  • 請求書の分割
  • アクセス権の分離
  • クォータ管理の分離

リソースマネージャとリソースプロバイダ

リソースマネージャがAPIを受け付けて、リソースプロバイダがリソースを作成する。

リソースプロバイダには、Microsoft.Compute、Microsoft.Storage、Microsoft.Webなどがある。

新しいサブスクリプションを取得した直後はリソースプロバイダが登録されていない。リソースを作成すると自動でリソースプロバイダが登録される。但し、一部のリソースは手動で登録が必要。

リソースの移動

ほぼ代表的なリソースはすべて別のリソースグループやサブスクリプショングループに移動できる。

管理ツール

  • Azureポータル
  • Azure CLI
  • Azure PowerShell
  • Azure Cloud Shell
  • Azure Mobile App

ARMテンプレート

テンプレートの構造

  • $schema
  • contentVersion
  • parameters:デプロイするときに入力可能なパラメータ
  • variables:テンプレート内で使用する変数
  • resources
  • outputs

Azure AD

エディション

  • Azure AD Free
  • Azure AD Office 365 アプリ
  • Azure AD Premium P1
  • Azure AD Premium P2

テナント

テナントという単位で組織を管理する。テナントには1つのサブスクリプションが紐づけられる。

主な機能

  • オブジェクトの管理
  • MFA
  • 条件付きアクセス
  • セルフパスワードリセット

バイス登録

  • Azure ADデバイス登録
  • Azure AD参加
  • ハイブリッドAzure AD参加

環境管理

  • タグ
  • ロック
  • クォータ
  • Azure Advisor:使ってないリソースの削除を勧めてくれたりする
  • Azure Policy
  • RBAC
  • 管理グループ:複数のサブスクリプションをグループ化

コスト管理

主なコスト

  • 仮想マシン
  • ストレージ
  • ネットワーク:アウトバンド通信にコストがかかる

ツール

  • 料金計算ツール:料金のシミュレーション
  • コスト分析:集計にタグを活用できる
  • 予算:過大なコストの発生を防ぐ

コスト削減

Azure Policy

適用範囲(リソース以外すべてに適用できる) * テナント * 管理グループ * サブスクリプション * リソースグループ

※ 上位に割り当てられたポリシーを継承する

ポリシー定義

  • 使用できるリソースの種類
  • 許可されてないリソースの種類
  • 許可されている場所
  • 許可されている仮想マシンサイズSKU
  • ストレージアカウントを許可されているSKUで制限する必要がある
  • タグとその値をリソースに追加する

イニシアティブ定義

  • 複数のポリシーをグループ化

その他

  • ポリシー定義は既存のリソースに対しても評価される

RBAC

特徴

  • JSON形式
  • 組込みロールとカスタムロール
  • ロールはユーザやグループだけでなく、サービスプリンシパル(アプリケーション)にも割り当てられる

代表的な組込みロール

  • 所有者
  • 共同作成者:所有者同様フルコントロールのアクセス権を持つが、ユーザへの権限付与はできない
  • 閲覧者
  • ユーザアクセス管理者
  • 仮想マシンの共同作成者

ロールの構造(一部)

  • actions
  • notActions
  • assignableScopees

ロールの評価

  • 複数のロールが割り当てられた場合、割り当てられたロールの和集合が実際のアクセス許可となる。但し、各ロールのnotActionsは加算されない。

仮想マシン

仮想マシンの実体とは

  • MS社のデータセンターのラックに格納されたブレード上でHyper-Vサーバ(ホスト)が動作
  • ホスト上で仮想マシンを実行するのがAzure仮想マシンサービス

構成要素

  • CPU
  • メモリ
  • ディスク
  • ネットワークインターフェース

ディスク

  • 用途
    • OSディスク
    • 一時ディスク:規定でDドライブになる
    • データディスク
  • 種類
    • Standard HDD
    • Standard SSD
    • Premium SSD
    • Ultra Disk

イメージ

  • 大きく分けてWindowsLinuxのOSがある
  • OS単体ではなく、ミドルウェアや特定のアプリケーションがインストールできる

可用性セット

  • 障害ドメイン
    • いくつのラックに分散するか
    • 最大値は 3
  • 更新ドメイン
    • いくつのサーバグループに分散するか
    • 最大値は20

可用性ゾーン

代表的な拡張機能

監視

  • 診断エージェント:Diagnosticsエージェント。ゲストOSやアプリケーションが生成するログやパフォーマンスデータをストレージアカウントに収集してくれる
    • The Linux Diagnostic Extension should be used which downloads the Diagnostic Extension (LAD) agent on Linux server.

接続方法

  • RDP
  • SSH
  • Bastion

Bastion接続

  • RDPやSSHポートを外部公開せずにポート443を使ってAzureポータル上で仮想マシンに接続できる。
  • 仮想マシンが配置されているのと同じ仮想ネットワークに、Bastionだけを配置する専用のサブネットを作成する。サブネット名は「AzureBastionSubnet」でなければならない。サブネットアドレスのプレフィックス値は26以下でなければならない。
  • その後Bastionを作成してパブリックIPアドレスを割り当てる。仮想マシンにパブリックIPアドレスを割り当てる必要はない。

スケールセット

スケールセットの設定項目

  • 初期インスタンス
  • スケーリングポリシー
  • スケールインポリシー
  • アップグレードモード:手動、自動、ローリングの3種類
  • オーバープロビジョニング:有効だと、実際に要求された数より多くの仮想マシンを起動する。正常にプロビジョニングが確認できたときに余分なマシンを削除。これにより、展開時間が短縮される。

スケーリング設定

  • スケールアウトの規則は、いずれかが満たされていれば実行される
  • スケールインの規則は、すべてが満たされている場合に限って実行される。

ストレージアカウント

ストレージサービスの種類

  • Blobコンテナ
  • Azure Files
  • Azure Queue Storage
  • Azure Table Storage

ストレージアカウントの種類

※ アカウントの種類によって、サポートできるストレージサービスが異なる。

  • Standard汎用v2
  • PremiumブロックBLOB
  • Premiumファイル共有
  • PremiumページBLOB

レプリケーションオプション

  • LRS
    • データセンター内で3つのディスクにコピー
    • データセンターが火災や洪水になると利用できない
  • ZRS
    • 3つのゾーンにデータをコピー
  • GRS
    • データセンター内で3つのディスクにコピー
    • さらに別のリージョンのデータセンター内で3つのディスクにコピー
    • 合計6つのディスクにコピーされてる
    • 平常時はプライマリリージョンのみアクセス可能
  • RA-GRS
    • 平常時でもセカンダリリージョンは読み取りアクセス可能
    • 負荷分散できる
  • GZRS
    • 3つのゾーンにデータをコピー
    • さらに別のリージョンのデータセンター内で3つのディスク
    • 合計6つのディスクにコピーされてる
    • 平常時はプライマリリージョンのみアクセス可能
    • GRSとはプライマリリージョンでのレプリケーションに差異あり
  • RA-GZRS
    • 平常時でもセカンダリリージョンは読み取りアクセス可能
    • 負荷分散できる

ストレージセキュリティ

  • 安全な転送オプション
  • 論理的な削除
  • サービスエンドポイント
  • Shared Access Signature(SAS
  • Storge Service Encryption(SSE)

Azure Blob Storage(Blobコンテナ)

ストレージの形式

  • ファイルストレージ
  • ブロックストレージ
    • ブロック単位で管理やアクセスするストレージ
  • オブジェクトストレージ

BLOB Storageのリソース

  • ストレージアカウント > コンテナ― > バイナリラージオブジェクト という階層構造になっている

コンテナーのパブリックアクセスレベル

※1 下記はコンテナーでの設定

※2 インターネット経由でのアクセスを行うには、ストレージアカウントの設定で「BLOBパブリックアクセスを許可する」を有効にしておく

  • プライベート
    • インターネット経由でのアクセス禁止
    • Azure内部からのアクセスのみ可能
  • BLOB
    • インターネット経由でのアクセス可能
    • 但し、ファイルの一覧は取得不可
  • コンテナ―
    • インターネット経由でのアクセス可能
    • ファイルの一覧は取得可能

BLOBの種類

コンテナーにファイルをアップロードする際に、「BLOBの種類」というパラメータを選択する必要がある

  • ブロックBLOB
    • 一般的なファイルをアップロードする場合に適している
  • 追加BLOB
    • BLOBの末尾へのブロック追加ができる。既存ブロックの更新、削除はできない
    • ログの保管などに適している
  • ページBLOB
    • 512バイトのページの集まり
    • オンプレミスのHyper-V環境で作成したVHDファイルをアップロードして、Azure仮想マシンで使用したい場合に利用

アクセス層

  • ホット
  • クール
  • アーカイブ
    • 読み取りも変更も不可
    • 読み取りたい場合はホットやクールに切り替えが必要(リハイドレート)数時間以上かかる場合がある。

ライフサイクル管理

  • ライフサイクル管理ポリシーを設定し、アクセス層を自動で変更したり、ファイルを削除できる。

Azure Files

特徴

ストレージ層

接続

  • ポート番号 445が許可されている必要がある

Azure File Sync

  • Windowsファイルサーバーにファイルを同期(コピー)
  • 1対多での同期構成が可能
  • ディザスターリカバリに利用できる

コンポーネント

  • ストレージ同期サービス
    • Azure File Syncで使用するサーバーを登録するための最上位オブジェクト
    • 同期グループを管理する
  • 登録済みサーバー
    • ストレージ同期サービスに対象のWindowsサーバーを登録したもの
  • Azure File Syncエージェント
    • Windowsサーバーにインストールするエージェントプログラム
  • クラウドエンドポイント
  • サーバーエンドポイント
  • 同期グループ
    • クラウドエンドポイントとサーバーエンドポイント間の同期リレーションシップ

実装手順

  1. ストレージ同期サービスのデプロイ
  2. 同期対象のWindowsサーバーの準備
  3. WindowsサーバーへのFile Syncエージェントのインストール
  4. ストレージ同期サービスへのWindowsサーバー登録
  5. 同期グループおよびクラウドエンドポイントの作成
  6. サーバーエンドポイントの追加

サービスエンドポイント

  • インターネット経由でのアクセスをブロック
  • 指定した仮想ネットワークからのみアクセス許可
  • 同じリージョン内の仮想ネットワークとサービスインスタンスの間で機能する

暗号化キー

種類

  • Microsoftマネージドキー
  • カスタマーマネージドキー
    • Azure Key VaultまたはKey Vault HSMに保管される

ネットワークサービス

種類

仮想ネットワーク

  • 仮想ネットワークをまたぐ通信はできない
  • またぐ場合、ピアリング設定やVPNゲートウェイを使用する
  • 既定では同じ仮想ネットワーク内のサブネットはすべて通信可能
  • 後からアドレス空間の拡張が可能
  • ピアリング構成済みの場合は、一旦ピアリングを削除して、アドレス空間を変更後に再度ピアリングを設定する

プライベートIP

  • Azure内部DHCPサービスにより自動で割り当て
  • 静的な割り当ても可能。アドレスを指定できる

パブリックIP

  • 静的な割り当ても可能。アドレスは指定不可
  • DNS名を設定できる
    • <DNSラベル名>.<リージョン名>.cloudapp.azure.com
  • SKU
    • Basic
    • Standard
      • Basicに加えて可用性ゾーンがサポートされる

ネットワークセキュリティグループ

  • ネットワークインターフェース(NIC)またはサブネットに関連透けることができる
  • NICとサブネット両方にNSGを関連付けた場合は、両方の規則で許可されている必要がある
  • 1つのNIC(またはサブネット)に関連付けられるNSGは1つだけ
  • NSGのリージョンと関連付け先のNIC(またはサブネット)のリージョンは同じである必要がある
  • 受信/送信セキュリティ規則に分かれている
  • 規則は優先度順にチェックされ、優先度の高い規則に一致した場合、それより引く優先度の規則は適用されない

アプリケーションセキュリティグループ

  • 複数の仮想マシンNICをグループ化したもの
  • ASGをNSGの規則の送信元および宛先として使用できる

Azure Firewall

  • 仮想ネットワーク全体でのネットワークフィルタリングにはNSGよりもAzure Firewallの方が優れている
  • Azure Firewallに複数の仮想ネットワークを関連付けられる

実装手順

  1. Azure Firewallを配置する仮想ネットワークとサブネットを作成する。既存の仮想ネットワーク上に作成してもよい。サブネット名は「AzureFirewallSubnet」で、プレフィックスは/26以下でなければならない
  2. Azure Firewallをデプロイする
  3. ルートテーブルを作成し、サブネットに関連付ける。ルートテーブルではアウトバウンドのトラヒックがAzure Firewallを経由するように設定する。
  4. ファイアウォールポリシーと規則の作成

規則

  • ネットワーク規則
    • アウトバウント、インバウンドの両方に適用される
    • IPプロトコルとポート番号を指定し、条件に一致したトラヒックを許可/拒否する
  • アプリケーション規則
    • アウトバウンドに適用される
    • 仮想ネットワークからアクセス可能な宛先をFQDNで指定
    • 一致するネットワーク規則が存在しなかった場合のみ適用される
  • DNAT規則
    • インバウンドに適用される
    • 受信トラヒックのアドレス変換とフィルタリングを行う
    • ファイアウォールのパブリックIPとポートをプライベートIPと別のポートに変換する
    • 例えば、ファイアウォールのパブリックIPのポート2000番宛てに届いたパケットを、10.0.0.4のポート3389宛てに変換する

Azure DNS

目的

  • 外部の名前解決(DNSゾーン)
  • 内部の名前解決(プライベートDNSゾーン)

DNSゾーン(DNS委任)

プライベートDNSゾーン

  • 解決仮想ネットワーク
    • 動的にレコード登録されない
  • 登録仮想ネットワーク
    • 動的にレコード登録される(IPアドレスVM名=FQDNがAレコードとして登録される)
    • 動的登録は仮想マシンが起動しているときのみ行われる

ピアリング

異なる仮想ネットワーク間では通信できないので、ピアリングが必要になる。

  • 仮想ネットワークピアリング
    • 同じリージョン内でのピアリング
  • グローバル仮想ネットワークピアリング
    • 異なるリージョン間のピアリング

特徴、注意点

  • 異なるサブスクリプション、異なるテナント間でもピアリング可能
  • 仮想ネットワークのアドレス空間が重複していると、ピアリングできない
  • ピアリングは双方向の設定が必要
  • ピアリングは推移しない。3つの仮想ネットワークが連なってピアリングされているとき、間にある仮想ネットワークをまたいでの接続はできない。必ず1対1でのピアリング接続が必要
  • ピアリング済みの仮想ネットワークでアドレス空間を変更する場合は、いったんピアリングを削除する必要がある

ピアリングの選択肢

VPNゲートウェイ

特徴

VPNゲートウェイを使用した構成

  • サイト間接続
    • オンプレとVnetを接続
  • ポイント対サイト接続
    • PCとVnetを接続
  • Vnet間接続
    • インターネットではなく、Azureバックボーンネットワークを経由

サイト間VPN接続手順

  1. Vnetおよびサブネット作成
    1. サブネットはVPNゲートウェイ専用で、サブネット名はGatewaySubnetでなければならない。アドレスプレフィックス長は/27か/28が推奨
  2. VPNゲートウェイの作成
  3. ローカルネットワークゲートウェイの作成
    1. オンプレミス側のVPNバイスを登録するために、ローカルネットワークゲートウェイというリソースを作成する
  4. 「接続」の作成
    1. 「接続」というリソースを作成することで、VPNゲートウェイとオンプレのVPNバイスが接続される

VPNゲートウェイの種類

  • VPN
  • ExpressRoute

VPNの種類

※ 一度作成したら変更不可。削除 & 再作成が必要となる。

  • ポリシーベース
    • IPsecポリシーに基づいて、パケット送信
    • サイト間接続でのみ使用可能、SKUはテスト・評価用のBasic SKUに限定
  • ルートベース
    • ルーティングに基づいて、パケット送信
    • ほとんどのVPNゲートウェイでルートベースが使用される
    • サイト間接続、ポイント対サイト接続、Vnet間接続をサポート

VPNゲートウェイのSKU

  • 世代毎にSKUタイプがある。Basic SKUはテスト評価用
  • Basic SKU以外はBGPをサポート

可用性モード

VPNゲートウェイを作成されると、内部的には2つのインスタンスがデプロイされる。この2つのインスタンスは既定でアクティブ / スタンバイになっている

  • アクティブ / スタンバイ
    • メンテナンスだと切り替えに15秒程度かかる
    • 障害だと切り替えに3分程度かかる
  • アクティブ / アクティブ
    • Basic SKUを除き、有効化可能
    • 作成後に変更することもできる
    • VPNゲートウェイに2つ目のパブリックIPの割り当てが必要
    • オンプレのVPNバイスで2つのパブリックIPと2つのVPNトンネルを受け入れるよう構成が必要

Express Route

  • VPNゲートウェイだとサイト間接続がインターネット経由になる
  • 通信の遅延やロスが発生する可能性あり
  • Express Routeは閉域網でオンプレとマイクロソフトデータセンターをつなぐ

選択肢

  • 接続プロバイダー
  • サポートされる帯域幅
  • 冗長性を備えた背t図億
  • 接続可能なクラウドサービス
  • 課金モデル
    • 従量課金
    • 無制限
  • SKU
    • ローカル
    • Standard
    • Premium

接続方法

  • ポイントツーポイントのイーサネット接続
  • Cloud Exchangeでの同一場所配置
  • 任意の環境間ネットワーク

2種類のExpress Routeピアリング

  • Azureプライベートピアリング
    • Vnetとの接続に使用
    • VnetのプライベートIPアドレスで接続できる
  • Microsoftピアリング
    • Azure PaaSサービスとの接続に使用
    • パブリックIPのみ
    • オンプレ側でNATを使用して、プライベートIPをパブリックIPに変換する必要あり

実装手順

  1. Express Route回線の作成
  2. Express Routeピアリングの構成
  3. Express Routeゲートウェイの作成
  4. 接続の作成

Virtual WAN

スキップ

ルートテーブル

システムルート

  • 既定で、サブネットに対してシステムルートが割り当てられている
  • システムルートには既定でいくつかのルート情報が含まれている
  • ピアリングやサービスエンドポイントの機能を有効にすると、システムルートにルート情報が追加される

ユーザー定義ルート

  • ユーザーが独自に定義するルート情報
  • システムルートよりも優先度が高い
  • 重複したルートはユーザー定義ルートによりオーバーライドされる

ユーザー定義ルートの作成

  1. ルートテーブルの作成
  2. ルートの追加
  3. サブネットへの関連付け

サービスエンドポイント

  • Azure内部からインターネット経由を経由せずにPaaSサービスにアクセスできる
  • Vnet側の設定
    • 任意のサブネットに対して、サービスエンドポイントを使いたいサービスを選択する(Microsoft.StorageやMicrosoft.Sql等)
  • サービス側の設定
    • ストレージの場合、ストレージアカウントのネットワーク管理画面からアクセス許可するVnetとサブネットを選択する
    • SQL Databaseの場合、管理画面の概要 > サーバーファイアウォールの設定で、アクセス許可するVnetとサブネットを選択する

プライベートエンドポイント(Private Link)

  • サービスエンドポイントもプライベートエンドポイントもどちらもインターネット経由せずにPaaSにアクセスできる
  • 違いは、サービスエンドポイントがパブリックIPでアクセスするのに対し、プライベートエンドポイントではプライベートIPでアクセスする

実装

  • Private Linkからプライベートエンドポイントの作成
    1. プライベートエンドポイントの名前を選択
    2. 接続対象のリソースを選択
    3. プライベートエンドポイントを設置するVnetとサブネットを選択

Azure Load Balancer

スキップ

Azure Application Gateway

スキップ

App Service

特徴

  • 手軽にWebアプリケーションとREST APIの実行環境を構築できる
  • PaaS。負荷分散や自動スケーリングができる。バージョンアップが用意。

利用可能な言語

App Serviceプラン

  • App ServiceはWebアプリを動かすためのコンピューティング環境
  • App Serviceプランを作成し、そのうえで動くApp Serviceを作成する
  • App Serviceプランの上で、複数のApp Serviceが動く

App Serviceプランの価格レベル

  • サイズとSKUによって決定される
  • Free、Shared、Basic
    • 開発、テスト用。自動スケールなし
  • Standard、Premium
    • 本番環境向け
  • Isolated
    • 高速なネットワーク環境で実行するミッションクリティカルなワークロード

デプロイスロット

  • Standard以上の価格レベルで利用可能
  • 動作している運用スロットとは別に、ステージングスロットを追加し、スワップにより切り替えできる

スケーリング

  • スケールアップ/ダウン、スケールアウト/インが可能
  • Standard以上であれば、カスタム自動スケーリングが可能

バックアップ

  • Standard価格レベル以上で使用可能
  • バックアップはストレージアカウントのBlobコンテナに保管される
  • 事前にストレージアカウントの作成が必要

コンテナサービス

  • コンテナーとは、アプリと実行環境を1つにまとめたもの

Azureのコンテナーサービス

Azure Container Instances(ACI)

特徴

  • 高速な起動(数秒)
  • インターネット公開もAzure内部のみ、どちらにも対応
  • CPU、メモリの柔軟な指定
  • Azure Filesでデータ保持
  • WinsowsコンテナーとLinuxのコンテナーをサポート
    • Windowsコンテナーは、ホストOSがWindowsで、Windows上でDockerランタイムとDockerコンテナが稼働させる
    • Linuxコンテナーは、ホストOSがLinuxで、Linux上でDockerランタイムとDockerコンテナが稼働させる

コンテナーインスタンスの作成

  • コンテナーイメージのソースを選択(コンテナレジストリから選択)
  • CPUのコア数とメモリを指定
  • ネットワークの種類を選択(パブリック、またはプライベート)

Azure Kubernetes Service(AKS

Kubernetesクラスターの作成

クラスター作成時に以下のパラメータを設定する

  • プリセット構成(Standard等)
  • Kubernetesバージョン
  • ノードプール
  • 仮想マシンスケールセットを有効にする
  • ネットワーク構成
    • kubenet
      • ノードに対してIPを割り当てる
      • ポッドはNATを使用してクラスター外と通信する
    • Azure CNI
      • すべてのポッドがサブネットからIPアドレスを取得する
      • VnetからプライベートIPを介してポッドに直接アクセスできる

ポッドの追加

  • YAMLファイルを読み込ませてポッドを追加する操作は、kubectlを使用してクラスターと対話しながら行う
  • Azure Cloud Shellには既定でkubectlがインストールされている
> az aks install-cli
> az aks get-credentials --resource-group <RG名> --name <クラスター名>
> kubectl get nodes
> kubectl apply -f <YAMLファイル名>
> kubectl get pod
> kubectl get svc

Azure Backup

  • Azure VMのディスクはVHDファイル
  • このVHDファイルはストレージアカウントに格納されている
  • Azure Backupは増分バックアップを行う
  • バックアップデータはRecoevery Servicesコンテナーに保存される
  • Recoevery ServicesコンテナーはGRSで構成される。そのため、6重のバックアップデータコピーになる。

3つのシナリオ

  • ファイルおよびフォルダーシステム状態の保護
    • Windows OSを実行するコンピューターにMARS(Microsoft Azure Recovery Services)エージェントを導入
    • ファイルとフォルダー、システム状態の保護を行う
    • MARSエージェントはAzure Backupエージェントとも呼ばれる
  • 仮想マシンの保護
    • 厳密には仮想マシンのディスクであるVHDファイルをバックアップ
    • 仮想マシン全体だけでなく、ファイル単位で回復できる
  • ワークロードの保護
    • ネットワークにSystem Center Data Protection Manager(DPM)をベースとしたMABS(Microsoft Azure Backup Server)を導入することで、ネットワーク上のWindowsコンピューターが実行するワークロードデータを保護する

Recovery Servicesコンテナー

  • Azure Backupのバックアップデータ格納先
  • Recovery Servicesコンテナーはバックアップするリソースと同じリージョンでなければならない

バックアップの動作

  • VMのスナップショットが作成され、バックアップデータとしてRecovery Servicesコンテナーに転送される
  • 実行中のWindows VMをバックアップした場合、VSSと連携してアプリ整合性スナップショットを取得する
  • Linuxではアプリの整合性は確保されないので、サービス停止してバックアップを取るか、MSが用意したスクリプトを使用する必要がある

実装手順

  1. Recovery Servicesコンテナーを作成する
  2. 仮想マシンのバックアップを選択する
  3. バックアップポリシーを構成する(バックアップ実行時刻や保持期間)
    1. 最大で9,999日保持することができる
  4. バックアップを行うマシンを選択する

※ バックアップ有効化後にRecovery Servicesコンテナーを削除するには、バックアップの停止とバックアップデータの完全な削除が必要

仮想マシンの保護」以外のシナリオ

  • ファイルおよびフォルダーシステム状態の保護
    • ワークロードの実行場所で「オンプレミス」を選択し、バックアップする内容で「ファイルとフォルダー」を選択する
    • MARSエージェントやコンテナー資格情報ファイルのダウンロードなどとともに手順が表示される
  • ワークロードの保護
    • ワークロードの実行場所で「オンプレミス」を選択し、バックアップする内容で「Microsoft SQL Server」や「Microsoft Exchange」を選択する

仮想マシンの復元オプション

Azure Site Recovery

スキップ

Azure Monitor

Azure Monitorが収集する監視データ

  • アプリケーション監視データ
  • ゲストOS監視データ
    • Azure Monitorエージェント、またはWindows Azure DiagnosticsやLinux Azure Diagnosticsといった拡張機能VMにインストールする必要がある
  • Azureリソース監視データ
  • Azureサブスクリプション監視データ
  • Azureテナント監視データ

データの種類

  • メトリック
    • 「モニター」の「メトリック」で参照できる
  • ログ
    • 「モニター」の「アクティビティログ」で参照できる
    • アクティビティログの保持期間は90日間で、保持期間は変更不可
    • それ以上長く保存したい場合はCSV形式でダウンロードするか、Log Analyticsワークスペースやストレージアカウントに送信する

アラート

  • メトリックやログに関する条件を指定し、一致する状況でアクションを実行できる
  • スコープ(アラートを出す対象)、条件、アクションの3つを指定する
  • アクションはアクショングループという単位で指定する
    • アクショングループにはAutomation Runbookを実行したり、通知を送信したりする
    • 通知にはレート制限がある
      • 電子メール:1時間で100件以下
      • SMS:5分間で1件以下
      • 音声:5分間で1件以下

Log Analytics

特徴

  • Azure Monitorの一部として統合された。新しい名称は「Azure Monitorログ」
  • ログデータに対してクエリを実行し、絞り込みや分析を行う
  • オンプレも監視できる
  • 保存したデータ量に基づいて課金。但し、一定量を超えるデータが収集されるまで料金は発生しない

Log Analyticsワークスペース

Log Analyticsエージェント * Windows用とLinux用がある * Windows用は「Microsoft Monitoringエージェント」(MMA)と呼ばれる * Linux用は「OMSエージェント」と呼ばれる * Azure MonitorエージェントはLog Analyticsエージェントの後継だが、完全に同等ではない * https://learn.microsoft.com/ja-jp/azure/azure-monitor/agents/azure-monitor-agent-migration

アクティビティログとの接続方法

  • アクティビティログ > 診断設定 > 診断設定を追加する
  • 収集するアクティビティログのカテゴリを選択し、宛先にLog Analyticsワークスペースを選択する

Azureリソースとの接続方法

  • Azure StorageやAzure Load Balancerなどと接続するケース
  • 対象リソースの「診断設定」 > 診断設定を追加する > 宛先にLog Analyticsワークスペースを選択する

Azure 仮想マシンとの接続方法

  • 対象の仮想マシンにLog Analyticsエージェントをインストールする
  • Log Analyticsワークスペースの画面で 仮想マシン > 接続 で対象のマシンを選択するとLog Analyticsエージェントがインストールできる
  • そのほかにもARMテンプレートやPowerShellを使用する方法がある

Log Analyticsエージェントの構成

  • エージェントを使用して監視データを収集するには、インストールとは別に、エージェントを使用して収集する監視データを選択しなければならない
  • Log Analyticsワークスペース > エージェント構成 > 収集するデータを指定

監視データの検索

  • 監視データの種類毎にテーブルを分けて管理される
  • テーブルには以下の種類がある
    • Event
    • Syslog
    • Perf
    • AzureActivity
    • AzureMetrics
  • データ保持期間は最大730日間
  • Kusto Query Languageで検索できる kql Event | search "error" Event | where EventLog == "System"

Network Watcher

Q&A

  • VMランサムウェアに感染した場合のリストア方法は?

    • Azure Backupで取得したバックアップをもとに新しくVMを作成する、あるいは既存のVMのディスクをバックアップとリプレイスする
  • Azure ADでAKSクラスターへの認証を提供する方法は?

  • テナントルートマネジメントグループへのアクセスはだれができる?

  • Azure ADでの条件付きアクセスポリシーの設定例は?

    • Azureポータルでアクセスしたときに、すべてのユーザがMFAを求められるという要件の場合、設定は以下のようになる
      • Select Users & Groups : Where you have to choose all users.
      • Select Cloud apps or actions: to specify the Azure portal
      • Grant: to grant the MFA.
  • 外部のパートナー社員がマイクロソフトアカウントでAzureにアクセスしたい場合はどのように設定すればいい?

  • Azure Import/Exportサービスが使えるストレージアカウントは?

    • ストレージアカウントの種類
      • Standard General Purpose v2 storage accounts (recommended for most scenarios)
      • Blob Storage accounts
      • General Purpose v1 storage accounts (both Classic or Azure Resource Manager deployments)
    • ストレージサービスの種類
      • Import supports Azure Blob storage and Azure File storage
      • Export supports Azure Blob storage
  • ストレージサービスのTableをサポートしているのはどのストレージアカウント?

    • General Purpose v1 storage
    • General Purpose v2 storage
  • Recovery Servicesコンテナーが削除できない場合は何を確認すべき?

    • バックアップが停止されていることを確認すべき
  • Recovery Servicesコンテナーと保護対象のVMは別のリージョンでもいける?

    • 保護対象のVMはRecovery Servicesコンテナーと同じリージョンでなければならない
  • Azure Backupでバックアップできるストレージサービスは?

    • ファイル共有のみ
    • そのほかには、Azure Backupでバックアップできるもの
      • Azure VM
      • Azure VMSQL
      • Azure VM の SAP HANA
      • Azure ファイル共有
      • Azure Backup エージェント
      • Azure Backup Server
      • System Center DPM
  • AzCopyでコピーできるストレージサービスは?

    • Azure Blob storage
    • Azure File storage
  • Azure Monitorエージェントで取得したログでアラートを出力する方法は_

  • VMを別のVnetに移動するには?

    • 移動は無理。
    • やるとしたら、VMを削除して、アタッチされていたディスクで新しいVMを別のVnetに作成する
  • DNSのゾーンファイルのインポート・エクスポートはできるのか?

注意点

  • VM作成のためにARMテンプレートを作成する場合、リソースグループだけはテンプレートに入れられない。なので、デプロイする際に入力する必要がある。

  • Desired State Configuration(DSC)でVMのソフトウェア管理を行う場合に、VMは稼働している必要がある

  • NICに表示されるPublic IPがIPアドレスではなく、名前になっている場合、VMはオフラインになっている

  • 標準の SKU パブリック IP 構成を持つか、パブリック IP 構成を持たないバックエンド プール内の仮想マシンのみをLoad Balancerに接続できます。 VM のパブリック IP は動的であるため、IP は Basic SKU IP である必要があります。このような VM (Basic SKU IP を使用) を Standard SKU ロード バランサーに追加することはできません。パブリック IP を削除するか、Standard SKU IP に変換しない限り、VM は選択のためにバックエンド プール ポータルに表示されません。

    • Standard SKU パブリック IP:静的IP
    • Basic SKU パブリック IP:動的または静的IP
  • パブリックロードバランサーは、NSGを設定しない限り、バックエンドプールにいるVMトラヒックが届かない。

  • No more than 20% of the Scale Set upgrading at any time, then 2 machines out of 10 will have maintenance, the 8 remaining VMs will be up.

    • Virtual machine scale sets are created with five fault domains by default in Azure regions with no zones. For the regions that support zonal deployment of virtual machine scale sets and this option is selected, the default value of the fault domain count is 1 for each of the zones. FD=1 in this case implies that the VM instances belonging to the scale set will be spread across many racks on a best effort basis.
  • Each availability set can be configured with up to 3 fault domains and 20 update domains.

  • Zone-redundant gateways and zonal gateways both rely on the Azure public IP resource Standard SKU. The configuration of the Azure public IP resource determines whether the gateway that you deploy is zone-redundant, or zonal. If you create a public IP resource with a Basic SKU, the gateway will not have any zone redundancy, and the gateway resources will be regional.

Protocol Buffersを試してみる

今回は、この辺りを参考にしながらプロトコルバッファ(Protobuf)を試してみる。

tech.raksul.com

nansystem.com

developers.google.com

Protobufを調べていると、Message Packも目にすることが多い。

MessagePack、Protobufも両方ともシリアライズ・デシリアライズの機能があるので比較されるのだろう。

MessagePackがシリアライズ・デシリアライズの速度に重きを置いている。

一方、Protobufではシリアライズ・デシリアライズの速度はMessagePackと比べると遅いようだが、データ構造を記述して共有することができる。つまり、XMLJSONと同じようにスキーマを記述することができる。

uqichi.hatenablog.com

frsyuki.hatenablog.com

今回はProtobufで、どのようにスキーマを記述するのか、シリアライズ・デシリアライズをどうやるのかについて調べる。

Protobuf を Windows にインストール

何はともあれインストールする。

qiita.com

>protoc --version
libprotoc 3.21.9

>pip install protobuf
>pip list
Package                  Version
------------------------ ---------
protobuf                 4.21.6

.protoファイルを作成し、コンパイルしてみる

user.protoファイルを作成する。中身はこんな感じ。

syntax = "proto3";

package hands_on;

message GetUserRequest {
  int32 id = 1;
}

message User {
  int32 id = 1;
  string name = 2;
}

service UserApi {
  rpc GetUser (GetUserRequest) returns (User);
}

細かい説明は後述するので、ここでは概略のみ。

syntax = "proto3";は、Protocol Buffersのシンタックスのバージョンを指している。

次に、package hands_on;だが、これはhands_onという名前空間package)を定義している。

message GetUserRequest {...}では、GetUserRequestという名前のメッセージフォーマット(データ構造、スキーマ)を定義している。

次に、.protoファイルをコンパイルする。Pythonで利用できるuser_pb2.pyが作成される。

>protoc --python_out=./test user.proto
> dir test
2022/11/20  01:16    <DIR>          .
2022/11/20  01:16    <DIR>          ..
2022/11/20  01:16             1,239 user_pb2.py

user_pb2.pyの中身はコチラ。

# -*- coding: utf-8 -*-
# Generated by the protocol buffer compiler.  DO NOT EDIT!
# source: user.proto
"""Generated protocol buffer code."""
from google.protobuf.internal import builder as _builder
from google.protobuf import descriptor as _descriptor
from google.protobuf import descriptor_pool as _descriptor_pool
from google.protobuf import symbol_database as _symbol_database
# @@protoc_insertion_point(imports)

_sym_db = _symbol_database.Default()




DESCRIPTOR = _descriptor_pool.Default().AddSerializedFile(b'\n\nuser.proto\x12\x08hands_on\"\x1c\n\x0eGetUserRequest\x12\n\n\x02id\x18\x01 \x01(\x05\" \n\x04User\x12\n\n\x02id\x18\x01 \x01(\x05\x12\x0c\n\x04name\x18\x02 \x01(\t2>\n\x07UserApi\x12\x33\n\x07GetUser\x12\x18.hands_on.GetUserRequest\x1a\x0e.hands_on.Userb\x06proto3')

_builder.BuildMessageAndEnumDescriptors(DESCRIPTOR, globals())
_builder.BuildTopDescriptorsAndMessages(DESCRIPTOR, 'user_pb2', globals())
if _descriptor._USE_C_DESCRIPTORS == False:

  DESCRIPTOR._options = None
  _GETUSERREQUEST._serialized_start=24
  _GETUSERREQUEST._serialized_end=52
  _USER._serialized_start=54
  _USER._serialized_end=86
  _USERAPI._serialized_start=88
  _USERAPI._serialized_end=150
# @@protoc_insertion_point(module_scope)

main.pyを作成し、user_pb2.pyをインポートしてスキーマを試してみる。

main.py

import user_pb2 

user_rq = user_pb2.GetUserRequest()
user    = user_pb2.User() 

print("Request ID is", user_rq.id)
print("User ID is", user.id)
print("Username is", user.name ,"\n")

user_rq.id = 1
user.id    = 1
user.name  = "Mazda"

print("Request ID is", user_rq.id)
print("User ID is", user.id)
print("Username is", user.name ,"\n")

user_rq.id = 1
user.id    = "Honda"
user.name  = "Mazda"

print("Request ID is", user_rq.id)
print("User ID is", user.id)
print("Username is", user.name ,"\n")

これを実行した結果がコチラ。

> python .\main.py
Request ID is 0
User ID is 0
Username is

Request ID is 1
User ID is 1
Username is Mazda

Traceback (most recent call last):
  File "C:\Users\xxx\Documents\Protobuf\test\main.py", line 19, in <module>
    user.id    = "Honda"
TypeError: 'str' object cannot be interpreted as an integer

↑から、int型の初期値は0、string型の初期値は空文字になっていることがわかる。

スキーマでint型と定義した変数にstring型を入れようとするとTypeErrorとなる。

このようにスキーマ定義に沿わないとちゃんとエラーにしてくれる。

次にmain2.pyを作成して、シリアライズ、デシリアライズを試してみる。

main2.py

import user_pb2 

user    = user_pb2.User() 

user.id    = 1
user.name  = "Mazda"

serialized = user.SerializeToString()
print(serialized)

deserialized_user = user_pb2.User() 
deserialized_user.ParseFromString(serialized)
print(deserialized_user)

実行結果は下記の通り。シリアライズして、デシリアライズできている。

> python main2.py
b'\x08\x01\x12\x05Mazda'
id: 1
name: "Mazda"

スキーマの説明

syntax = "proto3";

message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

syntax = "proto3";は、Protocol Buffersのシンタックスのバージョンを指している。

Protocol Buffersのシンタックスバージョンは、現在proto2proto3がある。

デフォルトはproto2なので、proto3を使用する場合はこのように指定する必要がある。

メッセージSearchRequestのなかに、3つのフィールドが定義されている。フィールドにはデータ型と名前が定義される。

フィールドは、メッセージ内でユニークな番号(フィールド番号)を持っている。フィールド番号はバイナリフォーマットにしたときにフィールドを特定するのに利用される。

詳細については以下が参考になりそう。

developers.google.com

qiita.com

本格的に使うことになったら、以下のGoogleのドキュメント(詳細な言語仕様)を読む。

developers.google.com

簡単だけど以上。

「Tableau徹底入門」を読んでみた

概要

「Tableau徹底入門」を読み、内容をまとめる。でも、第1章全体と第5章の一部のみしか読んでないです。。

第1章 データソースの作成

第5章 Tableauをさらに活用するための機能

読んでみての感想

表やグラフを作成する前段階のデータソース作成に関して、結構ページ数が割かれていて嬉しかった。

あとはパフォーマンスチューニングや通知機能についても触れられていて良かった。

リレーションシップの仕組みについてはもうちょっと知りたかった。

Tableau 製品

以下のような製品スイートがある。細かい製品はもっといっぱいある。

Tableau製品と価格体系について

  • Tableau Prep
  • Tableau Desktop
  • Tableau Sever & Tableau Cloud
  • Tableau Mobile

Tableau Prepでデータの前処理を行って、それをTableau DesktopないしTableau Sever & Tableau Cloudで可視化して、Tableau Sever & Tableau Cloudで共有するという感じ。Tableau Mobile使うと、スマホダッシュボードが見られる。

用語

  • データソース (.tdsファイル)
    • データの接続先から読み込んだデータ(接続先の情報、フィールドのデータ型、計算フィールドの定義、テーブル結合処理などが含まれる)
  • 抽出 (.hyperファイル)
    • データソースの接続タイプを抽出にした際に作成される接続先のデータのコピー
  • ワークブック (.twbファイル)
    • 1つあるいは複数のデータソースをもとにグラフを作る作業スペースのこと。データソース、ワークシートやダッシュボードの情報が含まれる。
  • ワークシート
    • ワークブック内で表やグラフを作成する画面
  • ダッシュボード
    • 複数のワークシートをもとに表やグラフを1つの画面上に表示するもの
  • ストーリー
    • 情報を伝達するために連携して機能する一連の視覚化、らしい
  • ビュー
    • ワークシートで作成した単一の表やグラフを表示するもの
  • プロジェクト
    • 数の子プロジェクトやワークブックを束ねたもの
  • パッケージドデータソース (.tdsxファイル)
    • 抽出とデータソースを一体にしたファイル形式
  • パッケージドワークブック
    • ワークブックに加えて抽出や、画像ファイル等のワークブックで利用されたローカルファイルを含むファイル

マイTableauリポジトリ

Tableau Desktop に関連するファイルが配置されるフォルダのこと。Tableau Desktopで利用するワークブック、データソースなどのファイルが格納される。Tableau Desktop をインストールすると自動的に作成される。

NULLについて

  • DIV関数で任意の数を0で割ると、エラーにはならずNULLが返ってくる。Tableauでは計算不可能な場合はNULLを返す。
  • 値がデータ型で許容されない場合にもNULLになる。例えば、日本語文字列をINT型に型変換する。
  • ZN関数はNULLを0に変換する
  • IFNULL関数でNULLを任意の値に変換することもできる。

集計、グループ化

特に忘れそうな点もないのでスキップする。

【コラム】ファントラップ (Fan Trap)

例えば売上明細テーブルを商品テーブルと紐づけるとする。紐づけには商品コードを使用する。

商品テーブルに同一の商品コードが複数あった場合、つまり商品コードが重複していた場合、結合した結果、元の売上明細テーブルよりもレコード数が増えてしまうことがある。この状態で、売上合計を計算すると、実際より売上が多く計算されてしまう。

関係(リレーションシップ)という機能を利用するとファントラップを避けながら結合を行うことができる。

カスタムSQL

データベースにあるテーブルやビューを読み込むのではなく、Tableau上で定義したSQLの実行結果に対して接続する機能。

データガバナンスの観点から非推奨。ベストプラクティスとしては、データベース側でテーブルやマテリアライズドビューを作成し、それに対して接続する。

リレーションシップ(関係)

複数のテーブルをスマートに統合するTableauの機能らしい。

  • リレーションシップは定義された時点では結合は行わない。統合が行われるのはワークシートで両方のテーブルのフィールドが利用された場合。片方のテーブルだけでビューが作成可能な場合は、テーブルの統合は行われない。

  • 「結合前の状態」の集計結果に対して統合を行うので、ファントラップを避けられる。「結合前の状態」の集計結果に対して統合を行うというのがどういうことかというと、条件となる値でそれぞれのテーブルを集計し、その集計結果を結合するようなイメージらしい。ファントラップは結合によって行が複製された集計していたため行が増えてしまっていたが、それが防げる。

  • リレーションシップでは結合タイプがディメンションとメジャーによって動的に変わる。

パフォーマンスオプションを利用したリレーションシップの最適化

パフォーマンスオプションを変更することで、リレーションシップの処理を最適化し、パフォーマンスを改善することができる。

  • カーディナリティ
    • テーブル間の結合条件を満たす行数の関係。デフォルト&推奨設定は「多数:多数」。
  • 参照整合性
    • すべてのレコードが一致:テーブルのフィールドが持つすべての値が、もう片方のテーブルのフィールド値に必ず一致する
    • 一部のレコードが一致:デフォルト&推奨設定。テーブルのフィールドが持つ値が、もう片方のテーブルのフィールド値に一部しか一致しない。あるいは、一致する程度が不明。

論理レイヤーと物理レイヤー

  • 論理レイヤ― 論理テーブル間をリレーションシップで統合する。

  • 物理レイヤー 物理テーブルの「結合」や「ユニオン」を定義する。 複数の物理テーブルを結合&ユニオンし、1つの論理テーブルを作る。

クロスデータベース結合

BigqueryやExcelなど異なる接続先のテーブルを統合することができる。

データソースを設定する画面で「接続」の横にある「追加」ボタンをクリックすれば、新しい接続先を追加することができる。

接続タイプ

「ライブ接続」と「抽出接続」の2種類がある。パフォーマンスや利用できる関数に影響するので重要。

抽出接続ではTableauの環境でインメモリ処理を行う。そのため処理速度が早いケースが多い。さらに、抽出を頻繁に行うことでリアルタイムに近づけることはできる。以上のことから、一般的にライブ接続より抽出接続が選ばれることが多い。

さらに抽出接続だとTableauの関数をすべて利用できる。

また、抽出接続は接続先のサーバーに負荷をかけることもない。

  • ライブ接続 データソースが接続先に常時接続するため、最新のデータが取得できる。また、集計や結合といった処理のほとんどが接続先の環境で実行される。

  • 抽出接続 接続先のデータをコピーして、Tableau上に抽出ファイルを作成する。データソースは、Tableau上の抽出ファイルに接続する。抽出はTableauに最適化されたフォーマットであるため、処理の高速化が期待できる。

※ 接続先がExcelJson、PDF等の場合、ライブ接続と抽出接続はパフォーマンス面で大きな違いはない。ライブ接続を設定したとしても「シャドー抽出」と呼ばれるファイルを使って処理を高速化するため。

増分更新と完全更新

別投稿で触れてるのでスキップ。

抽出フィルターとデータソースフィルター

抽出フィルターで不要なデータを除外しておくことで、抽出ファイルのサイズを小さくすることができる。

データソースフィルターは、抽出ファイル作成後にフィルタリングを行うため、データソースフィルターでは抽出ファイルのサイズを小さくすることはできないことに注意。

パフォーマンスチューニング

一般的には、Webページの読み込み時間に3秒かかるとユーザーがストレスを感じるらしい。

パフォーマンスに問題がある場合はデータソース、ワークシート、ダッシュボードの順で調べていくのが良い。

  • データソース
    • 理由もないのにライブ接続になっている
    • 抽出接続のデータ量が大きすぎる
      • Tableau Cloudでは抽出の行数が1,000行を超えたあたりから徐々にパフォーマンスに影響が出てくる
      • 1億行を超えると3秒以内のレスポンスはかなり難しくなる
      • 対策としては抽出フィルターで不要なデータを除く。データソースの粒度が細かくなりすぎないようにする(例:日時→日付)
  • ワークシート
    • ビュー上のセル(点、マーク)の数が多すぎて、計算や描画に時間がかかる
    • 結合対象が極端に多いリレーションシップ
      • 対策としては論理レイヤーでのリレーションシップによる統合を少なくして、事前に物理レイヤーで結合をしておく
  • ダッシュボード
    • ダッシュボードに表示するワークシートが多すぎる
      • ワークシートの数が20枚を超えると描画に数秒かかるようになる
    • ダッシュボードのサイズが固定になってない
      • サイズを固定することでTableau Cloud上でキャッシュが使用されやすくなる

パフォーマンスの記録

「パフォーマンスの記録」という機能でボトルネックを特定できる。

ワークシートやSQLをもとにボトルネックを分析できる。

「ヘルプ」→「設定とパフォーマンス」→「パフォーマンスの記録を開始」

パブリッシュ

ワークブックやデータソースをTableau Cloudに公開することをパブリッシュと呼ぶ。

推奨の接続構成

接続先からTableau Cloud上のデータソースに抽出。Tableau DesktopからTableau Cloud上のデータソースにライブ接続。

Tableau Bridge

ファイアウォールの内側からTableau Cloud上にデータを送信してくれる。

通知機能

  • サブスクリプション
  • データドリブンアラート
    • パブリッシュされたワークブックにあるメジャーが特定の条件を満たした際にメール配信やSlack通知を行う
    • アラート条件に利用したい数値がビュー上で字句として選択可能なことが条件
    • ワークシートを開き、ツールバーの「視聴」→「アラート」を選択する

Tableauの系列図(リネージ図)

動画で学ぶJSTQB

JSTQBシラバスはちょっとわかりにくいところがあるので、動画ないかなと探したところ↓のYouTubeに行きついた。

www.youtube.com

テスト技法

気になっていたテスト技法をリストアップしてみるとこんな感じ。

  • 静的テスト
    • アドホック:レビュアーに成果物を見せて意見をもらう
    • チェックリストベース:事前に用意したチェックリストに従って懸念事項を確認する
    • シナリオとドライラン:事前にシナリオを準備し、どういう動きになるか想像しながら予行演習(ドライラン)を行う
    • パースペクティブベース:最も効果が高い。様々なステークホルダーの視点でレビューを行う
  • 動的テスト

静的テストと動的テストは相互補完的なものでどちらが優れているということはない。動的テストで検出が難しい欠陥を少ない工数で検出できる。

ユースケーステストのユースケースは↓のようなもの。引用元サイトはこちら

JSTQBの範囲ではないけれど、C0/C1カバレッジという考え方もある。

C0カバレッジ率=実行行数÷全行数

C1カバレッジ率=実行分奇数÷全分岐数

www.youtube.com

テスト終了基準

  • 計画したテストが完了している
  • カバレッジ
  • 未解決欠陥件数が合意内に収まっている
  • 残存欠陥数が十分に少ない
  • 品質特性の評価レベルが十分

(感想)数だけでなく、「クリティカルな欠陥がないこと」も終了基準として重要ではないかと感じた。

テスト支援ツールの種類

  • 静的解析ツール
    • ソースコードを解析して、コーディングパターンに違反している個所を指摘してくれる
  • テストデータ準備ツール
  • テスト自動化ツール
    • 事前にテスト入力値とテスト実行結果の期待値を格納し、自動的(半自動的)にテストを実行してくれる
  • カバレッジルール
    • コードに対してどのくらいテストが完了したかを計算してくれる
  • 性能テストツール
  • 動的解析ツール
    • ソフトウェア実行中に欠陥を検出してくれる

テストツールのリスク

  • ツールの導入・メンテナンスのコストを過小評価してしまう
  • EOL等でツールが利用できなくなる
  • 新しい技術をサポートしない

OSS-DB Silverに合格しました

概要

仕事でPostgreSQLを使用する機会があり、せっかくなので試験を受けてみました。

勉強方法は、内部構造から学ぶPostgreSQL 設計・運用計画の鉄則、OSS教科書の順に一読して、Udemyの模擬試験をやりました。その後にOSS教科書の模擬試験にトライしました。OSS教科書の模擬試験は本番試験日当日にやったのですが、問題の出し方がハイレベルということもあり、正答率が5割弱でかなり焦りました。本番試験ぎりぎりまで誤答した問題を見直して試験に臨み、なんとか合格することができました💦

試験では割と細かいところまで問題に出ました。教材ではカバーしきれなかった問題も数問ありました。

学習期間は3週間弱でした。公式サイトに記載のある通り、2週間~1か月程度の準備で合格できると思いますが、油断することなく準備するのが良いと思います。

試験に利用した教材

OSS教科書 OSS-DB Silver Ver2.0対応

[改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則

OSS-DB Silver模擬試験問題集(6回分331問)

試験を受けてみた感想

PostgreSQLについてはほとんど知識がない状態でしたが、今回の試験を通じて体系的&効率的に学ぶことができました。

PostgreSQL未経験の方にはおススメの試験です。

利用した教材のうち、OSS教科書 OSS-DB Silver Ver2.0対応はわかりやすくまとめられていて、試験を受けない方にも非常におススメです。

CloudSQL for PostgreSQLのバックアップ

概要

CloudSQL for PostgreSQLのバックアップ方法がいくつかある。いったいどこまでバックアップされるのかがわからなかったので、それぞれを比較してみた。

用語

  • データベースフラグ

    CloudSQL for PostgreSQLではpostgresql.confといった設定ファイルにアクセスできない。その代わりにデータベースフラグというものがあり、これでPostgeSQLのパラメータ調整ができる。

比較結果

バックアップには以下の4パターンがある。

  1. インスタンスのクローンを作成(インスタンスをまるごとバックアップ)
  2. オンデマンド バックアップを作成(全てのデータベースをバックアップ)
  3. SQL ダンプファイルを使用したエクスポート(データベース毎にバックアップ)
  4. CSV ファイルを使用したエクスポート(テーブル毎にバックアップ)

1がもっともバックアップ範囲が広く、4がもっとも狭い。インスタンスをクローンすると、データベースフラグ(設定ファイルに相当)までバックアップすることができる。一方、CSV ファイルを使用したエクスポートではテーブルデータのみバックアップされる。

1.インスタンスのクローンを作成

Clone instances  |  Cloud SQL for PostgreSQL  |  Google Cloud

インスタンスのクローンを作成し、インスタンスをまるごとバックアップする。

新しいインスタンスには、新しい IP アドレスが割り振られが、設定(データベース フラグ、接続オプション、マシンタイプ、ストレージとメモリの設定)は元のインスタンスと同じになる。

引用元

対象 バックアップ範囲
データベースフラグ
ユーザー/ロール
データベース
オブジェクト権限
テーブル定義
テーブル

2.オンデマンド バックアップを作成

Create and manage on-demand and automatic backups  |  Cloud SQL for PostgreSQL  |  Google Cloud

オンデマンド バックアップの機能を使用することで全てのデータベースをバックアップする。データベースフラグはバックアップされない。

対象 バックアップ範囲
データベースフラグ ×
ユーザー/ロール
データベース
オブジェクト権限
テーブル定義
テーブル

3.SQL ダンプファイルを使用したエクスポート

Export and import using SQL dump files  |  Cloud SQL for PostgreSQL  |  Google Cloud

SQL ダンプファイルを使用したエクスポートの機能を使用し、データベース毎にバックアップする。SQLクエリとして出力される。

対象 バックアップ範囲
データベースフラグ ×
ユーザー/ロール ×
データベース ×
オブジェクト権限
テーブル定義
テーブル

4.CSV ファイルを使用したエクスポート

Export and import using CSV files  |  Cloud SQL for PostgreSQL  |  Google Cloud

CSV ファイルを使用したエクスポートの機能を使用し、テーブルデータをバックアップすることができる。エクスポートするレコードをSQLで指定できる。CSVファイルとして出力される。

対象 バックアップ範囲
データベースフラグ ×
ユーザー/ロール ×
権限 ×
データベース ×
オブジェクト権限 ×
テーブル定義 ×
テーブルデー