hitsumabushi845の日記

心理的安全性の保たれた空間に書く適当なメモ

『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション1~4

Kubernetes

qiita.com

というわけで、CKAD を取得したので引き続き CKA の取得へ向けて勉強していく。 CKAD と同様に Mumshad Mannambeth 氏の『Kubernetes Certified Administrator (CKA) with Practice Tests』を利用する。

www.udemy.com

CKAD を取得したので、今回は CKA 特有の項目について勉強を行い、時間をかけすぎてしまった CKAD よりも短期での取得を目指す。

Section 1: Introduction, Section 2: Core Concepts

これらのセクションはセクション 1 が CKA の説明、セクション 2 は CKAD と同様の内容であるので、今回はスキップ。

Section 3: Scheduling

このセクションでは、スケジューリング、つまり Pod などのリソースをどのノードにデプロイするかといった項目について説明される。 いくらかは CKAD で触れたものなので、"Practice Test を行う -> 分からなかったところがあったら説明の動画に戻る" といったステップで行う。 "分からなかったところ" の判定は "公式ドキュメントで説明されている場所が分からない", "公式ドキュメントを見ても分からない" といった場合に限定する。これは実際の試験で公式ドキュメントを参照できることから。

  • nodeName
    • もっともプリミティブな指定方法。ノード名を指定することで、そのノードへ Pod をスケジューリングできる。
  • Labels and Selectors
    • スケジューリングの観点では主に Deployments や ReplicaSets で登場する。
  • Taints and Tolerations
    • Taints が設定されたノードには、Tolerations が指定されていない場合はスケジューリングされない。
  • Node Affinity
    • label を用いて、スケジューリングするノードを指定できる
  • Resource Requirements and Limits
    • cpu や memory の request, limit について。
    • アプリケーションが使用するメモリよりも少ない memory limit を指定すると OOMKilled が発生する。
  • DaemonSets
    • 各ノードに1個 Pod 配置されることが保証されるリソース。
    • kube-proxy やオーバレイネットワークを提供する Pod は DaemonSet で提供される。
    • ほか、Monitoring プロセスが動く Pod などに使用される。
  • Static Pods
    • kubelet は単体で Pod を動かすことができる(kubelet が直接管理する Pod)
    • /etc/kubernetes/manifests に Pod のマニフェストファイルを配置すると、Pod が作成される。なお、このパスは kubelet の設定(起動時の --pod-manifest-path または設定ファイルの staticPodPath )で変更できる。
    • kubelet はこのディレクトリを監視していて、ここにマニフェストが配置されれば Pod を動かすし、削除されたら Pod を削除する。
    • この static pod は、主に controlplane のコンポーネントを管理するために利用される。controlplane が controlplane 自身に依存しないよう、kubelet が管理するようにする。
  • Multiple Schedulers
    • k8s のスケジューラは基本的に kube-scheduler が使われるが、複数のスケジューラを共存できる
    • kube-scheduler を複数立てることもでき、その名前は --scheduler-name で変更できる
    • 特定のリソースにおいてスケジューラを指定する場合は、spec.schedulerName に指定する

Section 4: Logging and Monitoring

このセクションでは、ロギングとモニタリングについて説明される。 クラスタのコンポーネントのロギング・モニタリング、並びにアプリケーションのロギングとモニタリングについて。

  • Monitor Cluster Components
    • k top コマンドについて。k top コマンドはノードや Pod のリソース利用率を確認できるコマンド。
    • 素の k8s では使えず、metrics-server を別途デプロイすることで利用可能となる。
    • 各ノードのリソース利用率を確認する場合は k top node、各 Pod の場合は k top pod。
  • Managing Application Logs
    • k logs コマンドについて。
    • 複数のコンテナからなる Pod のログを取る場合は、コンテナの名前を指定する。

セクション4はここまで。かなり短いセクションであった。

次回は Section 5: Application Lifecycle Management に取り組む。 目次を見る感じ結構 CKAD と被っていそうなのでサクッとできるとよい。

半年経ったので2021年の目標をふりかえる

雑記

2021年も半分がすぎたので、https://hitsumabushi845.hatenablog.com/entry/2021/01/02/092252 で掲げた目標について、現状を確認して下半期の動き方を考える。

資格をとる

今年受検したいと思っているものは以下の通り。 - CKA or CKAD
- TOEIC

CKAD は先日取得した。学習ログはこのブログに、受検ログは Qiita に投稿した。
考えてみると IT 系の資格を取ったのはこれがはじめてであった。試験自体久しぶりなのでかなり緊張した。

qiita.com

下半期は CKA の取得をはやめに済ませたい。
TOEIC は今年受けるかどうか微妙だなあ。

こまめにブログを書く

このブログでは特定の技術に関する話題以外の、技術以外の話やポエムなどを書いていきたいと思っている。
特定の技術要素については、せっかく Organization に属しているので Qiita に書くつもりでいる。 こまめにと言っても、せいぜい月2程度のペースでゆるくやっていきたい。

上半期、Qiita には 9 件の記事を投稿している。 このブログには主に CKAD の学習ログを投稿しており、合算すると月2のペースはクリアできている。

今後もこれくらいのペースで投稿できるとよい。

Terraform を勉強する

2021年から本業・副業ともに Terraform を扱うようなので、ゆるく勉強する。
仕事で使うのでまあ勉強できるだろうと高をくくっている。 特に到達目標はないが、仕事が回る程度に扱えればよいと思う。

これは具体的になにか勉強をしているわけではないが、業務で扱う中でなんとなく雰囲気は掴めた気がする。
ちなみに Terraform では GCP と OCI を主に扱っている。

golang を勉強する

そろそろ新しい言語を勉強したい。
golang は、複数のプラットフォームに向けてコンパイルできるということで、かねてより興味は持っていたが、
Kubernetes に触れるようになったことでより勉強するモチベーションが上がっている。 とりあえず、Gopher 道場 を進めていこう。

これが全然できていない。。 業務で必要にならないとやっぱりモチベーションが上がらないのがよくないところ。 必要になったらやろう（）

というわけで

まあおおむね目標通りに進んでいるように思う。 この調子で下半期もやっていければいいんじゃないでしょうか。

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション8

Kubernetes

引き続き、『Kubernetes Certified Application Developer (CKAD) with Tests』を進めていく。
今回は Section 8: State Persistence。ここまでで試験範囲は終わり。以降は Mock Exam(模試) となる。

Section 8: State Persistence

Volumes

コンテナが生成するデータ（ファイル）を永続化させるため、Pod に Volume をアタッチする。 以下に示すマニフェストでは、ノードの記憶領域をコンテナに /opt としてマウントしている。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - image: alpine
    name: alpine
    command: ["/bin/sh", "-c"]
    args: ["shuf -i 0-100 -n 1 >> /opt/number.out"]
    volumeMounts:
    - mountPath: /opt
      name: data-volume
  volumes:
  - name: data-volume
    hostPath:
      path: /data
      type: Directory

hostPath は特定のノード（Pod の配置されるノード）の記憶領域を利用するが、マルチノードの場合やノードのフェイルオーバーなど、ノードが替わった場合に一貫性が損なわれる。 そのため、通常は後述する Persistent Volume によりクラウドストレージ等を利用して永続化を図る。

volume の種別は他に、emptyDir, downwardAPI, projectedなどがある。 emptyDir は一時的な領域で、Pod が terminate されると削除される。downwardAPI は Pod の情報などをファイルとして保持するためのもの、projected は複数の volume をまとめるもの。

Persistent Volumes

Persistent Volumes(PV) は、ストレージ空間を提供するプールのような役割をしている。 大量の Pod をデプロイする場合に、各マニフェストで逐一 Volume を管理するのではなく、PV によって利用されるストレージを作成・管理し、Pod からは Persistent Volume Claim(PVC) を用いて利用する。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-sample
spec:
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  capacity:
    storage: 1Gi
  hostPath:
    path: /tmp/data

Persistent Volume Claims

先述した PV を Pod から利用するためのリソース。 accessModes や resources に指定した内容に合致する PV が紐付く。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-sample
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

素の k8s では、PV を作って PVC を作って... という流れで利用するが、GKE などではデフォルトでいい感じの StorageClass (kubernetes.io/gce-pd)が設定されており、PVC を作るだけで PV が Dynamic Provisioning される。

Storage Classes, Stateful Sets...

これらは CKAD の範囲ではないそうなので、今はスキップ。

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション7

Kubernetes

引き続き、『Kubernetes Certified Application Developer (CKAD) with Tests』を進めていく。
今回は Section 7: Services & Networking。

Section 7: Services & Networking

Services

k8s 内で動いている Web アプリケーションに対して、クラスタ外から単に Pod の IP アドレスにアクセスしてもアプリケーションへアクセスできない。
これは、Pod IP は異なるネットワークであり、クラスタ外からは見ることができないものだからだ。

クラスタ外から到達できる IP は基本的にノードの IP となる。そのため、ノードへのアクセスを所望の Pod に配分するリソースが必要となる。
この際作成するサービスは、例えば NodePort サービスが挙げられる。これはノードの特定のポートに来たリクエストと、指定した Pod や Deployment との間のやりとりを仲介するリソース。

ほかに、

  • ClusterIP
    クラスタ内でのみ疎通性のあるロードバランシング/ディスカバリを行うリソース。
  • LoadBalancer
    外部疎通性のある IP を払い出し、ノードに対するロードバランシングを提供するリソース。クラウドプロバイダが提供する LB を作成する。

などがある1。

NodePort Service はクラスタ内に作成された ClusterIP Service に対してノードの特定ポートを利用した外部疎通性を確保しているもので、トラフィックの経路としては Node の特定ポート -> ClusterIP Service -> Target Pod といった流れとなる。
同様に、LoadBalancer Service は NodePort Service に対する外部疎通性を確保するものである。

そのため、NodePort を作成したら内部的には ClusterIP も併せて作成され、LoadBalancer を作成したら NodePort も作成される。
このような ClusterIP <- NodePort <- LoadBalancer といった関係は、Pod <- ReplicaSet <- Deployment や、Job <- CronJob といった親子関係に似ている。

Services - ClusterIP

Deployment によって冗長化された Pod に対して、他の Pod からリクエストを送る場合、内部的なロードバランシングが必要となる。
この場合に利用されるのが ClusterIP Service であり、先述のとおりこれはクラスタ内でのみ利用可能な Service。

Ingress Networking

提供するサービスごとにコンテナを分けるといったマイクロサービス的なデプロイをした場合、サービス全体を外部公開した際にパスベースのルーティングを行いたいケースがある。
NodePort や LoadBalancer はあくまで L4 のロードバランシングを行うため、パスベースルーティングといった L7 のロードバランシングを行うためには、リバースプロキシのようなものが必要になる。

Ingress リソースは L7 のロードバランシングを提供する。
Pod や Service といったリソースのように、マニフェストファイルをもとに L7 ロードバランサを提供することができ、K8s 内で一貫した外部疎通性の確保が可能となる。

Ingress リソースは、デフォルトのクラスタでは提供されていない。多くのマネージド k8s では、クラウドプロバイダが提供する外部の LB と連携した Ingress Controller がデプロイされている。
そうでないクラスタ(オンプレミスのクラスタや Oracle Cloud Infrastructure の k8s などが該当する)では、Nginx controller を利用することとなる。

前者の外部 LB を利用した方法では、外部 LB がそれぞれの NodePort へトラフィックを転送する。
後者の場合は、クラスタ内に Nginx Ingress controller がデプロイされるため、別途 LoadBalancer や NodePort で外部疎通性を確保することとなる。LoadBalancer サービスは Nginx controller へトラフィックを転送し、Nginx controller が各 Pod へトラフィックを転送する。

Network Policies

Pod 間の通信ルールを設定するリソース NetworkPolicy について。
Kubernetes では、NetworkPolicy を設定しない場合は全ての通信が許可される。

NetworkPolicy では、Pod への通信である ingress rule と、Pod からの通信である egress rule を設定できる。 NetworkPolicy を設定した場合、そこで許可されていないトラフィックはすべて拒否される。

マニフェストの例は以下の通り。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Developing network policies

上記マニフェストの各種ルールについて。

  • ipBlock
    指定した CIDR から/へ の通信を許可する。
  • namespaceSelector
    指定した namespace から/へ の通信を許可する。
  • podSelector
    指定した Pod から/へ の通信を許可する。

from/to にリストのアイテムとして指定されたルールは、それぞれが or 条件として処理される。アイテム内に複数のルールを指定した場合は、and 条件として処理される。

  1. ほか、ExternalIP や ExternalName など。↩

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション6

Kubernetes

引き続き、『Kubernetes Certified Application Developer (CKAD) with Tests』を進めていく。
今回は Section 6: POD Design。

Section 6: POD Design

Labels, Selectors and Annotations

リソースを分類する方法について。
ラベルは metadata.labels に設定でき、設定したラベルにしたがって kubectl get pods --selector key=value といったように絞り込むことができる。

ReplicaSet や Deployment では、ラベルをもとに指定したリソースの数を判断している。 また、Service では、ターゲットとなるリソースをラベルから指定できる。

上述の通り、ラベルはリソースを分類・振り分けするためのフィールドだが、アノテーションはそのほかの情報を付与するためのフィールド。 ... と説明されているが、場合によってはアノテーションも分類・振り分け用途に使う気がする...

Rolling Updates & Rollbacks in Deployments

Deployment のローリングアップデートとロールバックについて。
Pod では、使用しているコンテナイメージを更新するためには Pod の再作成が必要になる。 一方、Deployment では配下の Pod についてコンテナイメージの更新をローリングアップデートで行える。

Deployment では、アップデート戦略(StrategyType)のデフォルトが RollingUpdate であるので、 ローリングアップデートは kubectl set image でイメージを変更するか、マニフェストを更新して kubectl apply をするだけでよい。
StrategyType を Recreate にすると、Deployment であっても再作成により更新が行われる。

変更のロールバックには kubectl rollout undo が使用される。リビジョンを指定しなかった場合は1つ前にもどる。
リビジョンは kubectl rollout history で確認できる。

ここのハンズオンは結構楽しい。Recreate と RollingUpdate の挙動について実際に手を動かして確認できた。

Jobs, CronJobs

Job について。
Pod などのリソースは常に動作していることが期待されるものだが、Job はバッチ処理など、特定の実行単位があり、終了する処理を行うリソース。

Pod でも終了する処理を実行することは可能だが、終了してしまうがゆえにヘルスチェックに失敗し、コンテナの再起動が走ってしまう。 また、Job では、同一の処理を並列で実行させたり、成功数を規定できたりする。

CronJob は、指定した時間に Job を作成するリソース。spec.schedule に cron と同じフォーマットで時間を指定できる。

apiVersion が、Job は batch/v1, CronJob は batch/v1beta1 なのに注意。

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション4・セクション5

Kubernetes

前回の記録から間が空いてしまったが引き続き、『Kubernetes Certified Application Developer (CKAD) with Tests』を進めていく。
今回は Section 4: Multi-Container PODs と Section 5: Observability。

これらのセクションは結構短い。

Section 4: Multi-Container PODs

マルチコンテナ Pod のパターンについて、アプリケーションコンテナとロギングを扱うコンテナの2つのコンテナを例に説明。このセクションは以下の説明と Practice test のみ。

  • Sidecar pattern
    アプリケーションコンテナのログをログサーバなどのサービスに送信するなど、補助的な機能をもつコンテナを配置する。
  • Adapter pattern
    アプリケーションコンテナのログをフォーマットするなど、外部とのインターフェースを提供するコンテナをもつパターン。アダプタコンテナがインターフェースを担うことで、アプリケーションコンテナ自身のログの柔軟性を高めることが出来る。
  • Ambassador pattern
    アプリケーションコンテナのログの送信先を扱うような、外部のサービスとの接続を仲介するコンテナを持つパターン。このコンテナがあることで、アプリケーションコンテナからは常にこのコンテナ(localhost)に接続すればよく、アンバサダーコンテナを差し替えることで接続先を柔軟に切り替えられる。

Practice Test は、Elasticsearch に Sidecar コンテナからログを送信し、Kibana からログを閲覧できるようにするハンズオンだった。といっても既存の Pod に指定のコンテナを追加するだけだが。

Section 5: Observability

Readiness Probes

Pod が作成されると、Pending -> ContainerCreating -> Running といったように、Status が遷移する。 コンテナが起動した後、"Running" であることを Kubernetes はどう知るのか？
Jenkins を Kubernetes で立ち上げると、Web 画面は利用可能でないが Pod は "Running" になる。 Service は "Running" な Pod にルーティングするので、アプリケーションとして利用可能でないのにルーティングされてしまう可能性がある。

そこで、アプリケーションが利用可能であること(リクエストを受け付けることができること)を Readiness Probes を用いて検証する。 これは HTTP API や TCP, コマンド実行で検証する。 この検証に失敗した場合、Service はその Pod へトラフィックをルーティングしない。

これは spec.containers[*].readinessProbe に設定する。

    readinessProbe:
      httpGet:
        path: /api/ready
        port: 8080
    readinessProbe:
      tcpSocket:
        port: 3306 
    readinessProbe:
      exec:
        command:
        - cat
        - /app/is_ready

Liveness Probes

Docker では、コンテナの作成に失敗したらそのコンテナは失敗したままだが、Kubernetes では Pod の作成に失敗したら、再作成を行う。 Pod の作成に成功したこと(Pod 内のコンテナが正常に動作していること)を検証するための機構が Liveness Probe。 この検証に失敗した場合、コンテナを再起動する。

こちらも同様に、HTTP API call や TCP, コマンド実行で検証を行う。

書き方は、おおむね Readiness Probe の readinessProbe を livenessProbe に変更したもの。

Container Logging

kubectl logs コマンドについて。Pod 名を指定して Pod のログを見たり、加えてコンテナ名を指定してコンテナのログを絞って見たり。ここは普段よく使っているので流す。

Monitor and Debug Applications

kubernetes のノード監視について。通常の運用では Prometheus や Datadog などを使ってメトリクスを記録していくが、CKAD では公式に開発されている Metrics Server を用いるようだ。過去は heapster というコンポーネントだったが、今は metrics-server らしい。

こいつはメモリ上に記録するため、メトリクスを過去に遡って見ることはできないが，kubectl top コマンドでノードや Pod のメトリクスを確認できるようになる。

7ヶ月かけて NURO を開通させた話

雑記

もうタイトルで言いたいこと全て言っているのだが、7ヶ月かけて NURO を開通させた。 これはなにも NURO の工事に7ヶ月待たされたという話ではなく、「初めての一人暮らし」であったり「賃貸物件の共用部への工事」といった要素が絡み合って時間がかかってしまった。

特に後者の「賃貸物件の共用部への工事」を解決するための戦いに多くの時間を費やし、先日ついに開通したためその記録を残したい。

引っ越しと1度目の宅内工事

昨年9月に実家を出る形で引っ越しをした。実家でも NURO を通していたこと、またリモートワーク環境を整えるための引っ越しであることから、引き続き NURO を利用しようと考えていたため、物件探しの段階で「NURO の工事が可能なこと」を条件に物件を探していた。

その後工事可能なマンションを契約し、引っ越し予定日に宅内工事を予約した。

そして宅内工事当日。 集合住宅の場合、宅内工事は宅内から MDF 盤まで光ファイバを通すことを目的とする。 つまり、部屋 (-> IDF) -> MDF といった経路で光ファイバを通すことになる。

MDF(Main Distribution Frame): 集合住宅やオフィスビルの共用部に設置される電話回線や光ファイバなどの集線装置。
IDF(Intermediate Distribution Frame): MDF から各戸分配するにあたって中間に設置される中継機器。複数フロアの物件の場合は通常各階に設置される。

しかし、この工事では 部屋 -> IDF の経路でファイバを通す途中でファイバが詰まってしまい、IDF まで通せないという事態に陥った。既設の電話回線等により配線を通すパイプが詰まっていたのである。

工事作業者と一緒になって、ファイバの通る音を頼りに詰まってしまっている地点を特定したが、そこは共用部（マンション廊下の天井裏）であり、またその地点に点検口などといったものが無かった。

そのため、この宅内工事では「別途点検口を設けるなどして、通線可能な状態にならない限り開通不可能」という結論となった。

ここでの学び

  • 入居前の「工事可能」はできるだけ厳密に確認しておく
  • 光アウトレットが既設の物件であればなおよい（こういった物件はほぼ築浅なので家賃は高い）
  • IDF とか MDF とか、このへんではじめて知った

点検口を開けてもらうための5ヶ月

さて通常、集合住宅かつ賃貸物件の場合は共用部へ点検口を設けるなどといった工事は許容されないことが多い。特に今回問題になっているのは 部屋 -> IDF の経路であるため、ここに点検口を設けるとなると他のフロアにも等しく設ける必要があるかもしれない。オーナーがこのコストを支払うのを避けたい気持ちは十分に理解できる。 しかしそもそも私は「工事が可能」という条件で物件を契約しているため、これを武器に戦うこととした（たとえ、この条件が不動産屋が深く考えずに発言した内容であっても）。

物件は私とオーナーとの間に管理会社が入っているので、まずは管理会社と交渉することになる。 ここからが長い戦いの始まりであった。

最初の1ヶ月

最初の1ヶ月は、まず管理会社に「なぜ NURO を通したいか」を理解していただくための期間であった。 集合住宅の場合、一口に光回線といっても各戸分配する方式によって品質が大きく変わる。（参考: https://internet-flets-campaign.net/column/separatefiber/ ）

このマンションには NTT の VDSL 設備はすでに備わっているため、対外的には「光回線が利用できます」と謳っていたし、管理会社の方もまた「光回線が利用できる」という認識であった。 そのおかげで、まず「なぜ NURO を通したいか」の説明が必要となった。

もちろん、光配線方式がとれればどの事業者でもよいので、個人的には NURO でもフレッツでも何でもよかった。 しかしフレッツはサービスとして VDSL と光配線の両方を提供している。 以下に示すやりとりを経て、「フレッツを利用したい」というスタンスでいると余計な混乱を招きそうと判断し、「NURO を通したい人」で通すことにした。

NTT の VDSL 設備が備わっている場合、VDSL 方式のフレッツ光は当然今のままでも利用可能である。 そのためか、管理会社から「フレッツなら光回線を通せます」という旨の回答を受けた。

この回答を逆手に取り、「フレッツ光なら通せるんですか？光配線方式でも？」 と質問したところ、おそらくあまり考えておらずに 「はい！通せます！」 と返ってきた。
もちろん通せるわけはないので、 「本当に通せるんですか？光配線方式って何か分かってますか？」 と改めて確認したところ、 「はい！わかります！」 と返ってきた。
分かっているとのことなので、改めて 「VDSL 方式と光配線方式の違いを説明できますか？」 と確認した。

すると 「ADSL ですか？」 と返ってきたため、改めてこれらの違いを説明し、理解いただいた。 ほかにも、「NURO が使える物件は付加価値が高まりますよ」的なことも（無責任に）言った気がする。

ここで辛抱強く説明を重ねて理解いただいたことで、以降管理会社の方がこちらの味方についてくれることとなる。このステップがなかったら以降の点検口開口の交渉も難しかったのではないかと思う。

これが最初の1ヶ月。

ここでの学び

  • 辛抱強く説明すると分かってくれることがある
  • 分かってくれると味方になってくれることがある
  • VDSL 方式と光配線方式の違いについて結構調べた

その後の3ヶ月

「なぜ NURO を通したいか」を理解いただいてからは、管理会社と物件オーナーとの交渉となる。 交渉の目的は点検口の工事可否確認になるのだが、先述の通り物件オーナーからすると共用部への工事は敬遠される。

さて、この期間は管理会社とオーナーの間での交渉が行われていたため、基本的に私がすることはなかった。 この間に私がしていたことは主に以下の2つである。

進捗確認

1つ目が進捗の確認。これは管理会社側が交渉の進捗をこちらに報告してくれないためであった。そもそもこちらから問い合わせないと報告しないというスタンスならそれでよかったが、彼らはいつも「いついつまでに改めてご連絡します」と言っていたのにも関わらずそれを守らなかったのであった。思い返してみると、これが守られたことは1度もなかったように思う。

そのため、平均的には2週間に1度、多いときは週に1度のペースで確認を取っていた。

直接引き込みの可否確認

そして2つ目が「点検口を開けずに工事を行う方法の確認」である。 そもそも私は「ただ単に点検口を開けたいだけの人」ではなく「NURO を通したい人」であるので、点検口を開けずに工事が可能ならそれでも良かったのだ。

点検口を開ける必要があるのは 部屋 -> IDF -> MDF といった経路での通線を行う場合であって、直接部屋に引き込むことができればその限りではない。実際 NURO は集合住宅であっても場合によっては部屋に直接引き込むことが可能である。(参考: https://www.nuro.jp/article/mansionjyouken/)

つまり、for マンションプランでなく通常プランであれば電柱から直接光回線を自室に引き込むことができる。通常プランは、以前は7階建て以下の集合住宅という条件があったものの、この条件は2019年に撤廃されたそうだ。

自室に直接引き込むことができれば、IDF や MDF のことを考えずに済むため、こちらの可能性についても検討した。

さて、自室に直接引き込むにあたり障壁となるのが「壁への穴開け」である。外壁から屋内にファイバを通すための穴開け、並びに穴へのカバー取り付けのためビス留めが必要となるのである。これらは外壁への穴開けとなり、賃貸物件の場合はほぼ容認されない工事となる。

しかし、これについても回避することが可能である。詳細はこの記事を確認してほしい。

要約すると、エアコン等の配管を利用してファイバを通し、ビス留めは両面テープで代替するなどの方法による回避である。

外壁への穴開けを回避できることが分かったため、管理会社に「外壁への穴開けがなければ工事してもよいか」、NURO に「私の住んでいる物件は直接引き込みが可能か」の確認をそれぞれ行った。

前者は穴開けがなければ良いとのことだったが、後者が不可能であった。つまり、私の住んでいる物件は直接引き込みができないのであった。

従って、NURO を開通させるにはやはり点検口を設けてもらうしかないということとなった。

そして

さて、これらのことを進めている間に管理会社とオーナー間の交渉は進んでいた。 管理会社の尽力のおかげか、オーナーの理解も得られ、点検口開口の工事が可能となったのである。

これが2021年1月中旬の出来事である。開始からすでに4ヶ月が経過していた。

ここでの学び

  • NURO は集合住宅であっても場合によっては直接引き込むことが可能
  • NURO は直接引き込みの際、場合によっては外壁に穴開けをしない施工が可能

最後の1ヶ月

ここは実際に点検口を開ける工事を待つだけのほぼ消化試合であった。 そして2月中旬、ついに点検口が誕生した。

つなぎの VDSL

引っ越し当初は、まず引っ越し予定日に宅内工事完了、その後1〜2ヶ月で屋外工事完了といったスケジュール感でいたため、モバイル Wi-Fi(WiMAX) をレンタルして仕事をしていた。

しかし、戦いが長丁場になりそうだったこと、モバイル Wi-Fi では仕事にならないことから、つなぎになる VDSL を契約することとした。

つなぎに利用する回線は、契約期間の縛りがないことが優先される。 NURO が開通できた場合即座に解約することとなるため、違約金等が発生するのは避けたい。また、契約期間の縛りがなければ、NURO の開通が不可能であった場合も改めて適切な事業者を選択することができる。

契約期間の縛りがないプロバイダは検索するといくつか出てくるが、enひかりを選択した。IPv6 オプションを追加することで IPoE での接続が行えるためだが、他でもできたかもしれない。

この VDSL は 12 月に開通した。都合 4 ヶ月で解約することとなったが、モバイル Wi-Fi から解放してくれて感謝している。

ここでの学び

  • NURO の工事待ちが長期化することが見込まれる場合、契約期間の縛りのないプロバイダを契約するとよい
  • モバイル Wi-Fi をレンタルし続けるくらいなら、さっさとつなぎの回線を契約した方がよい（工事費がかかるが、モバイル Wi-Fi による諸々のストレスをなくせるほうが大きい）

点検口が誕生し、2度目の宅内工事

点検口が誕生し、3月上旬、2度目の宅内工事が行われた。2度目の宅内工事では、1度目の工事と同じ作業者の方が来てくれた。作業者の方は1度目の工事のことを覚えてくださっていて、半年越しで工事を完了でき、お互いに戦友みたいな感じになった。

ただ、開けてもらった点検口の場所が微妙に良くなかったらしく、結局 IDF への通線は少し苦戦したらしい。

ともあれ、宅内工事が完了した。これが3月初頭。ここまでで5ヶ月半が経過していた。

そして終戦

宅内工事が完了し、残すは屋外工事のみとなった。NURO の屋外工事は長く待たされることで有名だが、私の場合は約1ヶ月半後の 4/22 に行われることとなった。 そして先日 4/22、ついに屋外工事が完了したわけである。

というわけで、VDSL と NURO の速度比較画像をもって本記事の結びとしたい。 なお、開通したプランとしては NURO 光 G2 V(旧: マンションミニ)プランである。

f:id:hitsumabushi845:20210504023218p:plain
VDSL

f:id:hitsumabushi845:20210504023249p:plain
NURO

余談

屋外工事にあたって、管理会社に連絡をしたところ、半年に渡って協力してくれた管理会社の担当の方が異動かなにかで担当を外れてしまっていた。最後にお礼を申し上げたいところだったが、叶わず。

ここでの学び

  • 光配線方式しか勝たん。
  • 半年経つと人は異動する可能性がある

おわりに

というわけで、7ヶ月かけて NURO の通っていない賃貸物件に NURO を開通させることに成功した。管理会社の方を味方につけたことや、（結果としてこの方法は取れなかったが）直接引き込みの検討など、様々なアプローチで NURO 開通へ向けて邁進したことがこの結果に繋がったのではないかと思う。

また会社の slack でこれらの進捗を逐一実況しており、多くの方が見守ってくれたことも支えとなった。開通したときは多くのリアクションをいただけて、ありがたい限り。

f:id:hitsumabushi845:20210504023614p:plain
開通したときのリアクション