Blog

笠原桃奈ちゃんすき

2020年振り返り

2020年も楽しかったですね。遅ればせながら振り返りを実施。

ライブ現場

基本的には笠原桃奈さんが出演する現場に行きました。サマリすると下記。

  • 2020冬ハロ: 2公演
  • 中島早貴舞台: 1公演
  • 中島早貴BD: 1公演
  • シリアルイベント: 3公演
  • アンジュルム ライブツアー 2020冬春 ROCK ON! LOCK ON!: 2公演(横浜2)
  • The Ballad 16人公演 : 5公演(中野4, 八王子1)
  • シリアルイベント1公演
  • 笠原桃奈BD: 1公演
  • さわやか五郎BD(ゲスト笠原桃奈): 1公演
  • The Ballad 4人公演: 2公演(沖縄)
  • The Ballad 武道館公演: 2公演(Extra Number, Special Number)
  • The Ballad 8人公演: 11(台場2, 立川2, 座間2, 横浜1, 渋谷1, 静岡2, 渋谷1)
  • アンジュルムコンサート起承転結: 1公演
  • アンジュルムクリスマスイベント: 2公演

合計: 35公演

すくない。印象的だった現場は下記。

2020/07/11 The Ballad 中野公演

約半年ぶりに推しの笠原桃奈さんを見た日。あなたに逢いたくてを歌っていた。歌詞の「あれから半年〜」「あなたに逢いたくて」が沁みた一日。

2020/10/01 シリアルイベント

コロナ禍でのニューシングルのシリアルイベント。約8ヶ月ぶりのアンジュルムだったが、室田瑞希さんがいなくなったアンジュルム。ダンスが今まで通りではないアンジュルムを見て、非常に落ち込んだ日。 在宅期間の間にたくさんのアンジュルムを見ていたので、ギャップが辛くてモチベが底を打った日。

2020/10/11 The Ballad 沖縄公演

モチベ底で行くか迷ったけど行ってよかったな。ライブハウスで凝縮された空間での4人公演は非常に密度が高い内容でした。この日は本当に会いに行ってよかった。

2020/10/22 笠原桃奈BD

Hello! Projectの楽曲を久しぶりに生で聴いた日。ファンを楽しませようという気持ちが伝わってきた素敵なセットリストでした。

2020/10/24 さわやか五郎BD(ゲスト笠原桃奈

今は亡きパシフィックヘブンで行われた笠原桃奈さんをゲストに迎えたさわやか五郎のBDイベント。 40名という超Closedな空間でのバースデーイベントは本当に楽しかった。トーク+4曲で40分。楽しかったという意味では一番かも。ありがとうさわごろ。

2020/12/09 アンジュルムコンサート起承転結

久しぶりにアンジュルムの楽曲を、踊っているアンジュルムを見た公演。赤いイヤホンのイントロで泣きそうになりました。

接触現場

  • 2020/07/xx: WithLive
  • 2020/08/12: WithLive
  • 2020/08/13: 新宿

これだけ。対面での謁見回数は120回ぐらい。

遠征回数

2回。すくない。

  • 沖縄
  • 静岡

良かった映画

映画は月に1-2本程度に見ているのでざざっと書きます。

ミッドサマー

最高でした。最高の映画体験です。見た日にディレクターズカットも一気に見た。こういうわけわからん体験をしに映画を見に行ってるんだよなぁ...。 嫌いな人もたくさんいるだろうけど、本当に大好きな映画です。

eiga.com

透明人間

冒頭の脱出シーンはなんどでも見たいようなオープニング。同じ舞台でのラストまで最高ですね。現代社会へのアナロジーはあんまり刺さらなかったけど映画として楽しかった。

eiga.com

ジョジョ・ラビット

スカーレット・ヨハンソンの演技がすごく好きだった。

eiga.com

良かった本/漫画

本は月1本程度のペースで読むので。漫画はもっとゆっくりと。中でも記憶に残っているものを。

三体2 黒暗森林

いやー良かった。最高でした。三体1も面白かったけれど、三体1で広がったでかいスケールの世界がもっと面白く描かれるとわね。悠久感があってとても良かったです。

www.amazon.co.jp

www.amazon.co.jp

ザ・ファシリテーター

仕事でファシリテートする必要があったので読んだ。ビジネス小説だったのであっさり読めた。今となってはどんな本か覚えてなかったが、直後のファシリテートイベントには役立った気がする。

www.amazon.co.jp

渚にて

核戦争後の人類の黄昏を描いた本。人類の最後の日々を哀愁、諸行無常感が素晴らしいSF小説でした。

www.amazon.co.jp

侍女の物語

多くの人間が生殖機能を失った世界。僅かな生殖機能を失わなかった女性たちが子どもを作るために男性に仕えるディストピアを描いたSF作品。自由な性への哀愁や羨望、回顧の文章が本当に素敵な小説でした。 これは年明けて読み終わったのだけど、書いたタイミングもあれなので載せます。

www.amazon.co.jp

チェンソーマン

2020年一番良かった漫画。これが週刊少年ジャンプで連載されていたこと。鬼滅の刃とともに連載されていたことが時代が変わったなと言う印象。

shonenjumpplus.com

葬送のフリーレン

評判を聴いて読んだ本。長命のフリーレンが死んでいった仲間を回顧しながら旅をする諸行無常感たっぷりな漫画。哀愁満ちる作風の中で結構コミカルな要素がバランスが良くて楽しい。

www.sunday-webry.com

裏バイト 逃亡禁止

垢抜けた都市伝説系の漫画。LSDでもやってんのかというぶっ飛んだ描写が素敵。

urasunday.com

良かったポッドキャストやラジオ

この2つは新たに聴き始めた

Replicant.fm

自分が体験してない人生を体験できる感じ。

medium.com

空気階段 踊り場

空気階段が面白い

www.tbsradio.jp

良かったゲーム

ゲームは常にやっているわけではないけど、年に数回やる程度。つまみながら生きてます。

FF7リメイク

オリジナルのFF7にはそこまで思い入れがあったわけではないけどやりました。ゲームとして難易度高めでやりごたえがあってめちゃくちゃ楽しめました。続編マダカナー

www.jp.square-enix.com

The Last of Us Part2

本当に最高のゲームでしたね。私の大好きな笠原桃奈さんが「おとなの掟」で歌っていた様に世の中には白黒つけるのは難しい。グレーな世界。どっちが正しい、良い、悪い。立場が変われば正解も変わる。コロナ禍の中でも非常にそのような事を思うことは多々ありました。このゲームでは、答えのないグレーな事を体験させてくれたゲームだったと思います。映画や小説ではなくゲームだからこそ、、、みたいなところがあって本当に素敵な作品でした。

store.playstation.com

買ってよかった商品、お世話になった商品

アイリスオーヤマ熱風オーブン

かなり安価な熱風オーブン。冷凍食品や自作の唐揚げやとんかつなど少量の油で揚げ物ができるスグレモノ。鳥肉を突っ込むだけで、素揚げになったりと最高。コロナ禍の中で自炊が増えた中でレパートリーを増やしてくれた製品。

www.amazon.co.jp

アルインコ エアロバイク

リモートワークが増えて運動量が減ったので購入。かなりコンパクトにしまえる上に、お家で軽くエクササイズができるのでとても良かった。映画とか見ながらできます。

www.amazon.co.jp

Switchbot

照明などの物理スイッチをスマートスピーカースマートフォンからOn/Offできるやつ。

www.switchbot.jp

アサヒブラックニッカクリア

まーじでたくさん飲んだ。安くてうまい(脳死

www.amazon.co.jp

神戸居留地炭酸水

ブラックニッカクリアと合わせて飲んだリーズナブルな炭酸水

item.rakuten.co.jp

侍女の物語

侍女の物語を読んだ。1990年に出版されたこの本。「パワー」という2019年に日本では出版された本が「現代版の侍女の物語」という記載だったのでどういう意味ないなのか?ということで手にとってみた。読みながら線を引いたところで、特に印象に残った部分を自分なりに文字にしていく。

その体育館には、懐かしい性の興奮と寂しさがあった。形もなく名づけることもできない何かへの期待があった。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 42-43). Kindle Edition.

冒頭のこのシーンから始まる体育館の描写が非常に特徴的。この物語全体を通して「妊娠のためだけの性交」が描写されるわけだが、それに伴う前時代への羨望や回顧のようなものがこの一文で表現されている。実際、日本の体育館であっても、若さや好意を寄せる女性への気持ちなど体育館を思い出す。良い。

わたしは彼女にとって屈辱だからだ。でも、わたしは彼女にとって必要な存在でもある。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 212-213). Kindle Edition.

このシーンは、「司令官」の妻であるセリーナ・ジョイにとって主人公のオブフレッドはどのような存在であるかを描写した一文。生殖機能を失った老女セリーナ・ジョイにとって、生殖機能を持った女性としてオブフレッドが描かれている。多くの人間が生殖機能を失った世界の歪な状態が作り出した社会を示している。

〈信仰の保護者〉のグリーンの制服を着ていて両肩とベレー帽に、白い三角形の上で二本の剣が交差した絵柄の紋章を付けている。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 377-378). Kindle Edition.

あまり意識して読むことはできなかったのだが、この世界の特徴として「侍女」は赤、「保護者」は緑などとロールによってユニフォームが決まっている。 このものがりの特徴。

わたしは力を、犬をじらす肉付き骨のような力を持っているのだ。それは受け身のものにすぎないけれど、確実に存在するのだ。わたしは、彼らがわたしたちの姿を見て勃起し、ペンキを塗られた柵にこっそり体を押しつけられずにいられなくなったらいいのにと思う。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 433-435). Kindle Edition.

このシーンは侍女の2人が「保護者」による通行許可を得てゲートを通り過ぎるシーンで、主人公のオブフレッドが脳内で彼らに対して望む事である。セックスが特権階級の人間しか許されない世界なので、当然そこらの「保護者」は自分ですませるしかない。前の時代を匂わせる作りだなーと思う。

彼らの陽気さは攻撃的で、目を逸らすことができない。あんな短いスカートをはいた女性を見るのは、ずいぶん久しぶりだ。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 562-563). Kindle Edition.

これは日本人(この世界やこの文化に染まっていない人々として登場する)が前時代のスタイルで街に繰り出していて、ツアーに来ている。侍女に写真をせがんだりするのだが、侍女としては拒否する必要があるのでこのシーンでは直接的なコミュニケーションなどは発生しないわけだが、ここも回顧を含んだ眼差してオブフレッドが日本人を見るシーン。特に、肌の露出などで性に関して。

日常とは、あなた方が慣れているもののことです、とリディア小母は言った。今はまだこの状態が日常には思えないかもしれません。でも、しばらくすればきっとそう思えるようになるはずです。これが日常になるのです。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 693-695). Kindle Edition.

これは突如として世界が一変したオブフレッドに向けたリディア小母のセリフ。コロナ禍の世界を生きていくなかで、この言葉はささったなー。本編とは関係ないけど。日常。

わたしたちは二本の脚を持った子宮にすぎない。聖なる器、歩く聖杯。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Location 2638). Kindle Edition.

生殖が役割の侍女の描写。

そこに書かれていたのは希望だったのだ。雑誌は変化を扱っていた。向き合わせておいた二枚の鏡に映る、次々とはてしなく並ぶ同じ像のように、可能性がどこまでもつづくことをほのめかしていた。ひとつの冒険から次の冒険へ、ひとつのファッションから次のファッションへ、ひとつの改良から次の改良へ、ひとりの男から次の男へ、次々と変えることを提案していた。それらは若返りを、痛みを克服して乗り越えることを、永遠の愛を呼びかけていた。それらの雑誌の本当の希望は不死の夢だった。

マーガレット アトウッド. 侍女の物語 (Japanese Edition) (Kindle Locations 2972-2976). Kindle Edition.

性的な描写が抑圧され、結果として異性を魅了するためのファッションなども抑圧された世界。カルチャーが無い世界。そこへの羨望。

とまぁこんな感じで性を扱う小説だなという感触を得ました。1990年頃はもっともっと性差がある世界だったはずなので、それはささったのでしょうか? 子どもを産むためだけの女性。専業主婦などは確かにそのような時代もあったかもしれない。女性の社会参加もかなり改善がされている(まだまだ格差はあるが)おり、その上でまた別の課題が多くあるのかな?とも思います。そういう意味ではナオミオルダーマンのパワー。これは女性が男性をリプレイスするような話なので、パワーが現代の課題をより詳細に語っている気もする。この直後からパワーを読み直してみようかと思う。また、パワーと侍女の物語との類似点としては、過去の遺物としてのドキュメントを見ているという点かなと。侍女の物語も最終章に歴史的考察として、この侍女の物語の文書は学者がまとめた文書であることが明らかになる。パワーも過ぎ去りし時代の物語として語られる。そのへんは大きな類似点、現代の侍女の物語とパワーが呼ばれる所以なのかなとも思います。とりあえずパワー読み返そう。。

Kubernetes 完全ガイド

 

第4章 APIリソースとkubectl

4.1 起動

  • gcloud init
  • gcloud container clusters create k8s --cluster-version 1.15.9-gke.26 --zone asia-northeast1-a --num-nodes 3
  • gcloud container clusters get-credentials k8s --zone asia-northeast1-a
  • kubectl create --save-config clusterrolebinding iam-cluster-admin-binding --clusterrole=cluster-admin --user=takedarut02@gmail.com

4.2 k8sの基礎

  • Node
    • Master
      • APIエンドポイントの影響
      • コンテナのスケジューリング
      • コンテナのスケーリング
    • Node
      • Dcokerホスト
  • 操作方法
    • 下記を用いる
    • これらをMaster nodeに対してリクエストを送付してk8sの操作を行う
      • RestAPIでできている
      • 直接呼び出してk8sを操作することも可能

4.3 k8sとリソース

  • k8sではリソースを登録することで、コンテナの実行やロードバランサの作成が非同期に行われる
  • リソースは多数あり、下記のAPIリファレンスで公開されている
  • リソースは下記の5種類が存在する
    • Workload
      • コンテナの実行に関わるリソース
    • Discovery & LB
      • コンテナを外部公開するようなエンドポイントを提供するリソース
    • Config & Storage
      • 設定・機密情報・永続化ボリュームなどに関するリソース
    • Cluster
      • セキュリティやクォータに関するリソース
    • Metadata
      • クラスタ内の他のリソースを操作するためのリソース
  • Workload
    • コンテナを起動するために利用するリソース
    • 下記の8種類のリソースが存在
      • Pod
      • ReplicationController
      • ReplicaSet
      • Deployment
      • DaemonSet
      • StatefulSet
      • Job
      • CronJob
  • Discovery & LB
    • エンドポイント提供のリソース
    • ServiceとIngressのに種類存在する
      • Service
        • ClusterIP
        • ExternalIP (One of ClusterIP)
        • NodePort
        • LoadBalancer
        • Headless (None)
        • ExternalName
        • None-Selector
      • Ingress
  • Config & Storage
    • 設定や機密データをコンテナに埋め込んだり、永続化ボリュームを提供するリソース
      • Secret
        • Key-Value
        • SecretとCoinfigMapは機密情報かどうかによって使い分ける
      • ConfigMap
      • PersistentVolumeClaim
        • コンテナから永続化ボリュームを要求する際に利用する
  • Cluster
    • クラスタ自体の振る舞いを定義する
      • Node
      • Namespace
      • PersistentVolume
      • ResourceQuota
      • ServiceAccount
      • Role
      • ClusterRole
      • RoleBinding
      • ClusterRoleBinding
      • NetworkPolicy
  • Metadata
    • クラスタ内のリソースを制御するためのリソース
      • LimitRange
      • HorizontalPodAutoscaler
      • PodDisruptionBudget
      • CustomResourceDefinition

4.4 Namespaceによる仮想的なクラスタの分離

  • Namespace
    • 仮想的なKubernetesクラスタの分離機能
    • 完全な分離ではない
    • 複数チームで利用
    • Production/Staging/developmentなどのように環境ごとに分割可能
  • kube-system
  • kube-public
    • 全ユーザーが利用できるConfigMapなどを配置
    • パブリックユーザー
  • default
    • デフォルトのNamespace
    • ユーザーが任意のリソースを利用できる
  • マネージド・サービスで構築されるNameSpaceのほとんどがRBAC (Role-based Accesss Control)になっている
    • クラスタに関する権限をNamespaceに対して分けることができる
    • Network Policyと組み合わせることでNamespace間通信の制御が行える仕組み
    • Namespaceだけではそこまでの分離性はないがこれらを利用して分離性を高める

4.5 CLIツールkubectl

  • kubectlがMasterと通信するには認証情報が必要
  • kubeconfigに記載されている情報で接続を実施する
    • cluster/users/contextsで設定する
      • cluster: 接続先のクラスタ情報
      • users: 認証情報
      • contexts: cluster, user, namaspaceの指定を行う
  • kubeconfigは直接編集も可能だが、kubectlコマンドで編集することも可能
  • 操作
    • clusterの作成
    • ユーザーの定義
      • kubectl config set-credentials admin-user --client-certificate=./sample.crt --client-key=./sample.key --embed-certs=true
    • Contextの定義
      • kubectl config set-credentials admin-user --client-certificate=./sample.crt --client-key=./sample.key --embed-certs=true
    • 現在のContextの表示
      • kubectl config set-context prd-admin --cluster=prd-cluster --user=admin-user --namespace=defalut
  • これらが冗長に感じる場合はkubectxやkubensを利用しても良い
  • マニフェストとリソースの作成・削除・更新
    • 一つのコンテナからなるPodを作成する
      • Podって
        • https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/explore/explore-intro/
        • Podには下記が含まれる
          • 共有ストレージ
          • ネットワーキング
          • コンテナのイメージバージョンや使用するポートなどの各コンテナをどのように動作させるかに関する情報
        • APサーバーとWebサーバーを含めることができる
        • pod内のコンテナはipアドレスとポートスペースを共有し、常に同じ場所に配置され、同じスケジュールに入れられ、同じノード上の共有コンテキストで実行できる
        • 最小単位
        • k8sにdeploymentを作成するとその中にコンテナを持つpodを作成します
        • 各podはスケジュールされているノードに関連付けられている。終了または削除されるまでそこに残る
        • ノードに障害が発生した場合同じpodがクラスター内の利用可能なノードにスケジュールされる
      • ノードって
        • Podはノード上で常に動作する
        • ノードはk8sのワーカーマシン
        • クラスタで仮想物理マシンでもよい
        • マスターはクラスター内のノード間でPodのスケジュールを自動的に処理する
          • マスターもノードの一種
          • マスター+ノードでクラスタ
    • podの作成
      • kubectl create -f sample-pod.yaml
    • podの削除
      • 通常終了
        • kubectl delete -f sample-pod.yaml
      • 強制終了
        • kubectl delete -f sample-pod.yaml --grace-period 0 --force
    • podの更新
      • kubectl apply -f sample-pod.yaml
      • yamlをupdate後に更新コマンドの実行
    • podの確認
      • バージョン確認
        • kubectl get pods sample-pod -o jsonpath={.spec.containers[].image}
      • 単純な稼働確認
        • kubectl get pods sample-pod

4.5.4 リソース作成にもkubectl applyを使うべき理由

  • kubectl applyで適用される差分
  • 今回追加/更新されるマニフェスト項目
  • 今回削除されるマニフェスト項目
  • 現在と前回って何が違うの?
    • 現在はシステムコンソールでいじることができる。
    • すなわち前回のコンフィグと同じ状態になっているとは限らない
    • そのため削除項目に関しては前回のマニフェストと比較を実施する
    • kubectl createは前回の状態が保存されない
    • 今回適用するマニフェストとの差分がわからなくなる、特定の設定値を削除できない場合は生じうるのでkubectl applyを利用するべき

4.5.5 マニフェストファイルの設計

4.5.6 アノテーションとラベル

  • アノテーション
    • metadat.annnotations
    • メモ書きのようなもの
    • 下記の3つの用途で利用される
      • システムコンポーネントのためにデータを保存する
      • すべての環境では利用できない設定を行う
      • 正式に組みこまれる前の機能の設定を行う
    • システムコンポーネントのためにデータを保存する
    • すべての環境では利用できない設定を行う
      • GKE、EKSはローカルIPアドレスを用いたインターナルエンドポイントの作成も可能
      • これらは特定のアノテーションを付与することで実現する
      • すべてのk8sで利用できないものに関してはアノテーションで制御できるようにしている
  • 正式に組み込まれる前の機能の設定を行う
  • ラベル
    • metadata.labels
    • リソースをぶっb熱するため
    • 多くのリソースを同一ラベルでグルーピングして処理したり、条件分に利用したりする
    • 下記の二週類ある
      • 開発者が利用するラベル
      • システムが利用するラベル
    • 開発者が利用するラベル
      • kubectlを用いて対象のリソースのみを操作することができる
      • -l -Lオプションとかあるよ
    • システムが利用するラベル
      • ラベル名は衝突する可能性あり
      • たとえばreplicas=3で起動しているPodに同じラベルでPod新たに起動すると既存のPodに影響がある可能性があります
      • LBも特定のラベルのものに流すとかが可能なので、よきせぬ自体が発生しうる
    • ラベルは
      • プロジェクト
      • アプリケーションの種類
      • アプリケーションのバージョン
      • 環境

4.5.7 Pruneによるリソースの削除

  • 手動でkubectlを実運用でするこてゃない
  • Git で管理しておいて、applyする方式が良い
  • --pruneでリソースの削除が可能
  • マニフェストファイル自体を削除しても、マニフェストファイル内の特定のリソースを削除しても反映される
  • Pruneの挙動
    • マニフェストファイルの削除された項目を削除しているように見えるが違う
    • ラベルに一致するすべてのものから削除されたものを削除している
    • したがってラベル指定が必須
    • --allオプション
      • マニフェストに読ませなかったリソース以外をすべて削除対象となる
      • 危険
    • ラベル設計はとても大事

4.5.8 エディタによる編集

  • kubectl edit
  • vi
  • export EDITOR=vim
  • kubectl edit pod sample-pod

4.5.9 リソースの一部情報の更新

  • kubectl set
  • これを用いて一部設定値のみ動作状態を変更することができる
    • env
    • image
    • resources
    • selector
    • serviceaccount
    • subject
  • kubectl describe pod sample-pod
    • コンテナイメージの確認
  • kubectl set iamge pod sample-pod nginx-container=nginx:1.12

4.5.10 リソースの情報取得(get)

  • kubectl get
  • これでリソースの一覧を取得できる
  • -l -L でラベル取得
  • -o で形式を指定もできる
  • Go Template

4.5.11 リソースの詳細情報の取得(describe)

  • リソースの詳細な情報を知りたい場合はkubectl describeを利用する

4.5.12 実際のリソースの利用料の確認(top)

  • Pod内のコンテナが利用しているリソースの使用量は kubectl top で確認可能

4.5.13 Pod上でのコマンドの実行(exec)

  • Pod上で特定のコマンドを実行したい場合は kubectl exec コマンドを利用しましょう
  • /bin/sh を利用すればコマンド実施可能
  • Pod内のコンテナ
    • kubectl exec -it sample-pod /bin/sh
  • 複数コンテナ履いたPod内で特定コンテナ
    • kubectl exec -it sample-pod -c nginx-container /bin/sh

4.5.14 Podのログ確認(log)

  • kubectl logs を利用する
  • kubectl logs sample-pod
  • kubectl logs sample-pod -c nginx-container
  • lubectl logs -f sample-pod
  • kubectl logs --sice=1h --tail=10 --timestamp=true sample-pod

4.5.15 Sternによる高度なログ確認

  • Sternを利用することで高度なログ出力が可能
  • 複数のコンソールを見る必要があるのがデフォルトだが、1つのコンソールで完結できるようになる

4.5.16 コンテナとローカルマシンの間でのファイルコピー(cp)

  • kubectl cp

4.5.17 ローカルマシンからPodへのポートフォワーディング(port-forward)

  • kubectl port-forward
  • これを実行時には複数のPodに対して分散して送信しているわけでなく、実行時にしていたものに配信される
  • ローカルホストの特定の通信を特定のPodに送信するようにする

4.5.18 kubectlの補完機能(completion)

4.5.19 kubectlにおけるデバッグ

  • -v でログレベルを指定することでできる
  • -v=6: HTTP通信概要
  • -v=8: 詳細まで

4.5.20 kubectlのその他のTIPS

  • alliasaの作成
  • kube-ps
  • Podが起動しないときのデバッグ
    • kubectl logs
    • kubectl describe
    • kubectl run
      • 実際のコンテナでの動作を確認してしまう

第5章 Workload リソース

5.1 Workloads リソースの概要

  • Podを最小単位として管理する上位リソースがある構造
  • Pod
    • ReplicationController
    • ReplicaSet
      • Deployment
    • DaemonSet
    • StatefulSet
    • job
      • CronJob

5.2 Pod

  • gggg1つ以上のコンテナで構成されている
  • PodごとにIPアドレスが割り当てられる
  • Pod内のコンテナはお互いにLocalhostで通信可能
  • 多くの場合は1pod 1container
  • サブコンテナの例
    • Proxy
    • 設定値の更新用
    • ローカルキャッシュ
    • SSL終端用
  • Podのデザインパターン
    • サイドカー
      • メインコンテナに機能を追加
    • アンバサダー
      • 外部システムとのやり取りの代理
    • アダプタ
    • サイドカー
        • 特定の変更検知下さいに動的に設定を変更するコンテナ
        • Gitリポジトリとローカルストレージを動悸する
        • アプリケーションのログファイルをオブジェクトストレージに転送するコンテナ
    • アンバサダー
      • ShardingされたDBやRedisなどに接続する際に結合度を下げるために、Proxy経由でアクセスをする
      • その結果Applicationはlocalhost経由でDBアクセスをするようになり、いい感じに疎結合になる
    • アダプター
      • 差分吸収
      • Prometheusなどのソフトウェアにあった決まったフォーマットでメトリクス収集を行う
      • その際の変換用のコンテナを内包する
  • Podの作成
    • 複数のPodを起動することが可能
    • Podないでポートかぶりが発生すると起動に失敗する
    • マニフェストファイルの先に記述があるものが起動する
  • コンテナへのログインとコマンドの実行
    • 擬似端末を生成-t, 標準入力をパススルー -i
    • コンテナないへ入る
      • kubectl exec -it sample-pod /bin/bash
    • コマンド実行
      • kubectl exec -it sample-pod ls
    • 特定コンテナを指定
      • kubectl exec -it sample-2pod -c nginx-container ls
    • オプション含むコマンド実行
      • kubectl exec -it sample-pod -- ls --all --classify
    • パイプを含むとき
      • kubectl exec -it sample-pod -- sh -c "ls --all --classify | grep media"
  • ENTRYPOINT/CMDとcommand/arfs
    • ENTRYPOINT → command
    • CMD → args
  • コンテナ内でのプロセスとかのインストール
    • apt update && apt -y install iproute procps
  • Pod名の制限
    • Pod名に制限あり
    • RFC1123に従う必要あり
      • 利用可能な文字は英小文字と数字
      • 利用可能な記号は-.
      • 始まりと終わりは英小文字
    • アンダーバーはだめよ
  • PodのDNS設定(dnsPolicy)とサービスディスカバリ
  • 静的な名前解決の設定

5.3 ReplicaSet/ReplicationController

  • Podのレプリカを作成して、その数のPodを維持し続けるリソース
  • ReplicationControllerは廃止の方向なので、ReplicaSetを利用するようにしましょう
  • ReplicaSetの作成
  • Podの停止とセルフヒーリング
k8s ryotaro$ kubectl get pods -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP         NODE                                 NOMINATED NODE   READINESS GATES
sample-rs-p7wsz   1/1     Running   0          7m45s   10.8.2.8   gke-k8s-default-pool-9a16beca-xvmz   <none>           <none>
sample-rs-sgtw5   1/1     Running   0          7m45s   10.8.1.6   gke-k8s-default-pool-9a16beca-dtgp   <none>           <none>
sample-rs-zh6z9   1/1     Running   0          7m45s   10.8.2.9   gke-k8s-default-pool-9a16beca-xvmz   <none>           <none>
k8s ryotaro$ kubectl delete pod sample-rs-p7wsz 
pod "sample-rs-p7wsz" deleted
k8s ryotaro$ 
k8s ryotaro$ 
k8s ryotaro$ kubectl delete pod sample-rs-p7wsz 
Error from server (NotFound): pods "sample-rs-p7wsz" not found
k8s ryotaro$ kubectl get pods -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP          NODE                                 NOMINATED NODE   READINESS GATES
sample-rs-rn7qw   1/1     Running   0          13s     10.8.0.11   gke-k8s-default-pool-9a16beca-nb6g   <none>           <none>
sample-rs-sgtw5   1/1     Running   0          8m12s   10.8.1.6    gke-k8s-default-pool-9a16beca-dtgp   <none>           <none>
sample-rs-zh6z9   1/1     Running   0          8m12s   10.8.2.9    gke-k8s-default-pool-9a16beca-xvmz   <none>           <none>
    • kubectl describe rs でpodの増減を確認可能
  • ReplicaSetとラベル
    • spec.selector.matchLabels で一致したラベルに対してReplicationを実施する
    • selectorで指定したラベルがtemplateにいない場合はエラーとなる
    • 追加した場合もどれかが死ぬ
  • ReplicaSetのスケーリング
    • スケールする方法は
      • マニフェストを書き換えて、 kubectl appluy -f する
        • sed -e 's/replicas: 3/replicas: 5/' sample-rs.yaml | kubectl apply -f -
        • Infrastructure as a code
      • kubectl scale コマンドを利用する
        • kubectl scale rs sample-rs --replicas 10
  • equality-based条件とset-based条件
    • set-basedを使おう
    • = とか in [aaa, bbb]などで記述する
    • 後日

5.4 Deployment

  • Deployment は ReplicaSet を管理することで、ローリングアップデートやロールバックを実現するリソース。
  • Deployment → ReplicaSet → Pod という3層構造
  • 基本的には下記のフロー
    • 新しいReplicaSetを作成
    • 新しいReplicaSet上のレプリカ数を徐々に増やす
    • 古いReplicaSet上のレプリカ数を徐々にへらす
    • くりかえす
    • 古いReplicaSetはレプリカ数0で維持する
  • Deploymentを利用するとこんな良いことが!
    • 新しいReplicaSetでコンテナが起動したことやヘルスチェックが通っていることを確認しながら切り替えを行ってくれる
    • 移行過程におけるPodの細かい指定も可能
    • Kubernetesにおける最も推奨されているコンテナの起動方法です
    • 単体コンテナでもDeploymentを利用するべき
    • 自動再生やローリングアップデートできません
  • Deployment の作成
    • 履歴を残しながら
      • kubectl apply -f sample-deployment.yaml --record
    • アップデート
      • kubectl set image deployment sample-deployment nginx-container=nginx:1.13
    • ロールアウト状況の確認
      • kubectl rollout status deployment sample-deployment
  • Deployment のアップデート(ReplicaSetが作成される)
    • Deploymentでは変更があるとReplicaSetされると説明しました
    • 作成されるPodの内容の変更が必要。
    • spec.templateに変更がある = 作成されるPodの変更
    • spec.template配下の構造体を用いたハッシュ値でラベル化している。そのため、戻して同じ構造にした場合はハッシュ値が一致するために、既存のReplicaSetを利用する
  • 変更のロールバック
    • Deploymentが作成したReplicaSetは基本的に履歴としてレプリカ0で形だけは残っているのでレプリカ数を増やすことで再度利用が可能
    • 変更履歴の確認方法
      • kubectl rollout history deployment sample-deployment
      • CHANGE-CAUSE
        • --recordオプションを用いたなかった場合は空になります
    • 該当リビジョンの詳細情報取得
      • kubectl rollout history deployment sample-deployment --revision 1
    • リビジョンを指定してロールバックする場合
      • kubectl rollout undo deployment sample-deployment --to-revision 1
    • 1つ前にロールバックする場合
      • kubectl rollout undo deployment sample-deployment
    • 実際はあんま使わない
    • Deplyment更新の一時停止
      • 更新を適用しても待ってほしいケースに対応するために、、、
      • 一時停止
        • kubectl rollout pause deployment sample-deployment
      • 一時停止解除
        • kubectl rollout resume deployment sample-deployment
      • この状況ではアップデートは待機状態のまま
      • ロールバックもできない
    • rolling-updateコマンド
      • 非推奨
    • Deploymentのアップデート戦略
      • Deploymentをアップデートするとローリングアップデートが実行された。
      • これはspec.strategy.typeがRoliingUpdateになっているため
      • アップデート戦略には下記の2種類の戦略がある
        • Recreate
        • RollingUpdate
      • Recreate
        • 一度すべてのPodを削除してから再度作成するので、ダウンタイムが入るが切り替えが早かったり、余剰なリソースを利用しない
      • RollingUpdate
        • 下記を設定可能
          • 許容される扶翼Pod数 : maxUnavailable
          • 超過Pod数: maxSurge
        • 個数でもパーセンテージでも指定可能
    • より詳細なアップデートパラメータ
      • minReadySeconds
        • PodがRedyになってからDeploymentリソース的にPod起動が完了したとみなすまでの最低秒数
        • 長くすれば待つのかな?
      • revisionHistoryLimit
      • progressDeadlineSeconds
    • Deploymentのスケーリング
      • kubectl scale or kubectl apply -f
    • マニフェストを書かずにDeploymentを作成する
      • kubectl run コマンドを利用することで、マニフェストを書かずにDeploymentを作成可能

5.5 DaemonSet

  • DaemonSetはReplicaSetの特殊な形とも言えるリソース
  • ReplicaSetは各Kubernetes Node上に合計でN個のPodをNodeのリソース状況に合わせて配置していく
  • DaemonSetは各ノードにPodを一つづつ配置するリリース
  • Podを配置したくない場合はにはそのようにすることができる
  • ユースケース
    • 各Podが出力するログをホスト単位で週憂愁するFluentdやDatadogなど各Nodeに必ず動作したいプロセスを利用することが多い
  • DaemonSetの作成
  • DaemonSetのアップデート戦略
    • アップデート戦略を選択することが可能
      • RollingUpdate
        • 随時Update
      • OnDelete
        • マニフェスト変更時にPodの更新をせず、別の要因でPodが更新されるときに新しい定義でPodを更新する
    • OnDelete
    • RollingUpdate

5.6 StatefulSet

  • こいつもReplicaSetの特殊系といえるリソース
  • データベースなどステートフルなワークロードに対応するためのリソース
  • ReplicaSetとの違いは
    • 作成されるPod名のサフィックスは数うじのインデックスが付与されたものになる
    • データを永続化するための仕組みを有している
      • persistentVolumeを使っている場合はPodの再起動時に同じディスクを利用して再作成される
      • Pod名が変わらない
  • StatefulSetの作成
    • PersistenVolumeClaimを設定することが可能
    • これを設定sることでクラスタ外のネットワークごしに提供されるPersistentVolumeにPodをアタッチすることができる
    • Pod再作成後も同じデータを保持した状態でコンテナが再作成されるようになる
    • https://github.com/Rtaro02/studyk8s/blob/master/sample-statefulset.yaml
    • ボリューム状態の要求
      • kubectl get persistentvolumeclaims
    • ボリュームの状態
      • kubectl get persistentvolumes
  • StatefulSetのスケーリング
    • kubectl scale
    • kubectl apply -f
    • レプリカ数の変更によるPodの作成・削除が発生した場合には1こずつ作成・削除するため時間がかかる
    • 並行でPodを作成しない
    • インデックスが多いものから作成され、削除されていく
      • ReplicaSetの場合はランダムに削除される
      • 特定のPodがマスターの場合はReplicaSetは向かない
      • StatefulSetの場合はindexが0のものは最初に作成・最後に削除なので向いている
  • StatefulSetのライフサイクル
  • StatefulStateのアップデート戦略
    • 下記2つ
      • RollingUpdate
      • OnDelete
    • OnDelete
      • DaemonSetと同様
    • RollingUpdate
      • StatefulSetでは永続化データがあるため、余分なPodを残してのローリングアップデートはできない
      • 一度に停止可能なPod数(maxUnavailable) を指定してからのローリングアップデートもできない、1つのPodずつアップデートを行います
      • partitionというパラメータを設定可能
        • 設定した値以下のインデックスのPodは更新されない。
        • 他のものはアップデートしまくります
        • spec.updateStrategy.rollingUpdate.partition で指定
  • 永続化領域のデータ保持の確認
    • Podを削除しても、プロレスをkillしても永続化データは保持されたまま
  • StatefulSetの削除とPersistentVolumeの削除
    • StatefulSetを削除してもPersistentVolumeは残ったまま
    • 再起動してもアクセス可能
    • 永続化領域を開放しよう
    •  kubectl delete persistentvolumeclaims www-sample-statefulset-{0..4}

5.7 Job

  • コンテナを利用して一度限りの処理を実行するリソース
  • N並列で実行しながら、指定した回数のコンテナの実行を保証するリソース
    • 3並列で5回実行が成功するまでPodを起動する例
  • ReplicaSetとの違いとJob使い所
    • ReplicaSetとの大きな違いは「起動するPodが停止することを前提にして作られているか」
    • Podの停止が正常終了となるような用途にむいている
      • 特定のさーばとのrsync
      • S3などのObject Storageへのアップロード
    • バッチ的な処理にはJobを積極的に利用しましょう
  • Jobの作成
  • restartPolicyによる挙動の違い
  • 並列Jobとワークキュー型の実行
    • 下記2点を設定していた
      • 成功回数
        • completions
      • 並列度
        • parallelism
      • これらはデフォルト値は1
    • completions/parallelism/backofflimitは非常に重要なパラメター
    • 下表の設定例、N,M,Pは任意の数
ワークロード
completion
成功数
parallelism
並行数
backoffLimit
終了判定失敗数
一回だけ実行するタスク
1
1
1
N並列で実行するタスク
M
N
P
1個ずつ実行するワークキュー
未指定
1
P
N並列で実行するワークキュー
未指定
N
P

5.8 CronJob

  • Jobに似たリソースとしてCronJobが存在する。
  • Jobの亜種に見言えるが、CronJobはJobと親子関係にある
    • CronJobがJobを管理し、JobがPodを管理するような体型になっている
  • Cronjobの一時停止
    • kubectl patch cronjob sample-cronjob -p '{"spec":{"suspend":true}}'
  • 同時実行に関する制御
    • 正常終了している限りは明示的に指定しなくても同時実行されることな新たなJobが作成される
    • 古いJobがまだ実行中の場合はポリシーで新たなJobを実行するかどうかの制御を行いたいケースがあります
    • このポリシーは spec.concurrencyPolicy で指定します
      • Allow
        • 同時実行忍耐して制御を行わない
      • Forbit
        • 前のJobが終了していない場合は、次のJobは実行しない
      • Replace
        • 前のジョブをキャンセルし、Jobを開始する
    • 実行開始期限に関する制御
      • 指定した時刻になるとKubernetes MasterがJobを作成する
        • この際にMasterがダウンしていた場合など、開始が遅れたときに許容できる秒数 (spec.startingDeadlineSeconds) を指定することができる
        • デフォルトではどんだけ遅れてもJobを開始するようになっている
    • Cronobの履歴
      • 保存していくJobの数を指定する
        • spec.successfulJobsHistoryLimit
          • 成功したJobを保存する数
        • spec.failedJobsHistoryLimit
          • 失敗したJobを保存する数
      • Jobが残っている = 紐づくPodも残っている

第6章 Discovery & LB リソース

6.1 Discovery & LBリソースの概要

  • Discovery & LBリソースには
    • クラスタ上のコンテナに対するエンドポイントの提供
    • ラベルに一致するコンテナのディスカバリに利用されるリソース
  • 2種類のリソースが存在する
    • L4ロードバランシングを提供するServiceリソース
    • L7ロードバランシングを提供するIngressリソース
  • Service
    • ClusterIP
    • ExternalIP
    • NodePort
    • LoadBalancer
    • Headless
    • ExternalName
    • None-Selector
  • Ingress

6.2 KubernetesクラスタのネットワークとService

  • Pod内には複数のコンテナがあるが、すべて同じIPアドレスが割り当てられている
  • 同じPod内であればlocalhost, 他のPodからであればIPアドレスを指定する
  • クラスタを構成するとノードにPodのための内部ネットワークを構成する
    • CNI(Container network)というモジュールの実装次第
    • ノード間のトラフィックがお互いが通信ができるように構成する
    • これらの内部ネットワークが自動構成をするためにPodはServiceを利用せずともPod間の通信を行うことが可能
    • しかしServiceのを利用することによるメリットは下記
    • これらの機能はどのService typeからも利用できる
  • Pod内のトラフィックのロードバランシング
    • Serviceは受信したトラフィックをPodにロードバランシングする機能を提供する
    • Serviceはロードバランシングの接続ぐちとなるエンドポイントを提供する
    • ClusterIPでは、ラベルで指定したアプリケーションに対してロードバランシングをする
  • クラスタDNSとサービスディスカバリ
    • サービスディスカバリってなんぞや
      • 特定の条件の対象となるメンバを列挙する
      • 名前からエンドポイントを判別する機能
    • サービスディスカバリの方法
      • 環境変数を利用したサービスディスカバリ
      • DNS Aレコードを利用したサービスディスカバリ
      • DNS SRVレコードを利用したサービスディスカバリ
    • 環境変数を利用したサービスディスカバリ
    • DNS Aレコードを用いたサービスディスカバリ
      • 他のPodからServiceで払い出されるエンドポイントへの接続するにはIP以外にもDNSレコードを利用することもできる。これを使うのが好ましい。
      • ClusterIP Serviceのメタデータに指定した名前でアクセス可能
        • FQDNはService名.Namespace.snv.cluster.local
        • Namespaceを名をつけて名前解決を行うがよさそう
      • 下記で検索は可能
        • kubectl run --image=centos:6 --restart=Never --rm -i testpod -- cat /etc/resolv.conf
      • 逆引きも可能
        • kubectl run --image=centos:6 --restart=Never --rm -i testpod -- dig -x 10.11.240.10
    • DNS SRV レコードを用いたサービスディスカバリ
      • ServiceのPort名.Protocol.ServiceName.Namespace.svc.cluster.local
      • SRVを解釈できる場合はこのようにサービスを提供しているPort番号を含めたエンドポイントまでDNSを解決することが可
    • クラスタDNSクラスタDNS

6.3 ClusterIP Service

  • クラスタ内ロードバランシングとしてはClusterIP Serviceが利用される
  • 何も設定していないとkubernetes serviceが作成されている
  • ClusterIP Serviceの作成
    • type: ClusterIP
    • 受け取りもと: spec.ports.port
    • てんそうさき: spec.ports.targetPort
  • ClusterIP 仮想IPの静的指定
    • 手動設定を利用する場合にはspec.clusterIPを利用する
    • kubectl applyでもclusterIPは設定変更できないimmutableな値
      • takedarut@RYOTARO-THINKPAD:~/repositories/k8s$ kubectl apply -f sample-clusterip-vip.yaml
      • The Service "sample-clusterip-vip" is invalid: spec.clusterIP: Invalid value: "10.11.253.83": field is immutable

6.4 ExternalIP Service

  • ExternalIP Service
    • 特定のKubernetes NodeのIPアドレス:Portで受信したトラフィックをコンテナに転送する形で外部疎通性を確立するService
    • ExternalIP Serviceの作成
      • typeはClusterIP
      • 設定するIPたち
        • spec.externalIP: Kubernetes NodeのIPアドレス
        • spec.ports.port: ExternalIP, ClusterIPで受け取るPort番号
        • spec.ports.targetPort: 転送先のコンテナのPort番号
      • ExternalIPに利用可能なIPアドレスはノード情報から確認することが可能
      • GKEの場合はGCEに割り当てられたOSから確認できるInternal IPのみ当てられる
      • ノードに直接グローバルIPがあられている場合は
        • kubectl get nodes -o custom-columns="NAME:{metadata.name},IP:{status.addresses[].address}"
      • ExternalIPを指定しないとしてい無しのときの外部IPあり版?
      • クラスタDNSがかえすIPはClusterIP
takedarut@RYOTARO-THINKPAD:~/repositories/k8s$ !366
kubectl run --image=centos:6 --restart=Never --rm -i testpod -- dig sample-externalip.default.svc.cluster.local
 
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 <<>> sample-externalip.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1333
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;sample-externalip.default.svc.cluster.local. IN        A
 
;; ANSWER SECTION:
sample-externalip.default.svc.cluster.local. 30 IN A 10.11.249.88
 
;; Query time: 2 msec
;; SERVER: 10.11.240.10#53(10.11.240.10)
;; WHEN: Wed Apr 15 13:07:55 2020
;; MSG SIZE  rcvd: 77
 
pod "testpod" deleted
takedarut@RYOTARO-THINKPAD:~/repositories/k8s$ kubectl get services
NAME                TYPE        CLUSTER-IP     EXTERNAL-IP             PORT(S)    AGE
kubernetes          ClusterIP   10.11.240.1    <none>                  443/TCP    4m11s
sample-clusterip    ClusterIP   10.11.246.59   <none>                  8080/TCP   102s
sample-externalip   ClusterIP   10.11.249.88   10.240.0.7,10.240.0.8   8080/TCP   2m35s

6.5 NodePort Service

  • ExternalIPに近いサービス
  • すべてのノードに対してListenするようなサービス。ExternalIPは設定したノードのみListenしていた。
  • spec.ports.nodePortに全K8sで受けるPortを指定する。全k8s上でバッティングしないようなPort選びが必要
    • 指定しないと空いている番号があたる
  • 30000 - 32767のポート範囲を指定しないとNG
  • ノード間通信の排除
    • 複数nodeある場合は、NodeのIP指定してもかってに別のNodeのPodにロードバランシングされてしまう
    • もし、特定のNodeのPodのみに通信したい場合は下記の設定を利用する
      • spec.externalTrafficPolicy
        • Cluster: 全部のPodにロードバランシングする。全Nodeに均等、、、というわけではなく自分のNodeへのリクエストが多くなる傾向にある模様
        • Local: 指定したNodeのPodのみにロードバランシングする。Node内にPodが複数ある場合は均等にロードバランシングする

6.6 Load Balancer Service

  • NodePortやExternalPortは結局NodeのIPを指定するので、そのIPがSPOFになりかねない。
  • Load Balancer Serviceはそんなことは起きない。なぜなら外部にLBを建てるので。
  • Nodeに障害が発生した場合には、そのNodeに対してトラフィックを転送しないようにする。自動的に復旧する要になっている。一定時間の通信断は発生する可能性あり。
  • LoadBalancer Serviceの作成
    • spec.ports.ports: LoadBalancerが払い出す仮想IPとClusterIPで受けるport
    • spec.ports.targerPort: 転送先コンテナのport
    • spec.ports.nodePort: 全k8s nodeのIPで受け付けるport番号
  • ノード間通信の排除
    • ノード上に対象のPodがない場合は通信できなくなってしまうので利用しないほうがベター
    • externalTrafficPolicyで指定
  • 静的IPの指定
    • LoadBalancerが払い出す仮想IPの指定
      • spec.loadBalancerIPで指定
      • GCPの場合は静的アドレスをダッシュボードから予約して指定する
  • ファイアーウォールの設定
    • LoadBalancerサービスはFirewallを指定することで実行可能
    • 未指定の場合は全世界に公開される
    • 場合によってはk8s側でアクセス制御が実装されていない。その場合はNetworkPolicyリソースの利用も検討が必要かも
    • GKEではtype: LoadBalancerを利用すると、GCLBが作成される。これ削除しないでGKEクラスタを消してもLBは残り続けるので注意。ちゃんと削除しような!

6.7 Headless Service (None)

  • Headless Serviceは対象のPodのIPアドレスが直接帰ってくるService
  • DNS Round robin でPodのIPが直接帰ってくっる
  • StatefulSetの場合のみPod名も名前解決可能
  • Headless Serviceの作成
    • 利用には下記の3条件を満たす必要がある
      • Serviceがspec.typeがClusterIP
      • Serviceのspec.clusterIPがNoneであること
      • Serviceのmetadata.nameがStatefulSetのspec.serviceNameと同じであること
    • 3爪の条件が満たされていいない場合には、DNS RRでディスカバリするHeadless Serviceとしてしか動作せず、Pod名を引くことができない

6.8 ExternalName Service

  • Service名の名前解決に対して任意の外部のCNAMEを返却することができる
  • 利用場面は別の名前を設定しない場合や、クラスタのエンドポイントを切り替えやすくするため
  • アプリケーションに外部アプリケーション名を書き込んでしまうとその書換が発生してしまう。デプロイし直しが発生する。そのため、ExternalNameを利用すると、アクセス先の切り替えをExternalName Serviceの切り替えを行うだけで可能になる
  • ServiceのFQDNを指定することでExternalNameのCNAMEレコードか、ClusterIPのAレコードが変えるようになる
    • ClusterIPからExternalNameに変更する場合は、spec.clusterIPを明示的に殻にしないとだめ
      • spec.clusterIP: ““
      • 明示的とは↑

6.9 None-Selector Service

  • 自分で指定したメンバに対してロードバランシングする
  • None-Selector ServiceではClusterIPのAレコードがかえる
  • アプリケーションからは同じClusterIPとして見せることができる
  • None-Selector Serviceの作成

6.10 Ingress

  • L7ロードバランシングを提供するサービス
  • kind: Ingressタイプのリソースをつかう
  • リソースとコントローラ
    • リソースをk8sに登録するところから処理が始まるが、コントローラーが実際の処理を実行する
  • Ingressリソースとコントローラ
  • Ingressの種類
  • クラスタ外のロードバランシング
    • Ingressリソースを作成するだけでLBの仮想IPが払い出される
    • クライアント → L7 → Pod
  • クラスタ内にIngress用のPodをデプロイするIngress
    • 内部にPodを作成する必要がある
    • Ingress用のPod宛にLoadBalancer Serviceを作成するなどの準備が必要
    • クライアント → L4 → Nginx → Pod
  • Ingressを利用する前の事前準備
    • 事前にServiceを作成する必要あり
    • Nordport経由の転送だったりするので
    • InrgessでHTTPSを利用する場合には事前に証明書をSecretリソースとして作成しておく必要がある

第7章 Config&Storage リソース

7.1 Config&Storage リソースの概要

  • 下記3種類のリソース
    • Secret
    • ConfigMap
    • PersistentVolumeClaim

7.2 環境変数の利用

  • Kubernetesでは個別のコンテナに対する設定は環境変数やだファイルが置かれた領域にマウントしてわたすことが一般的
  • Kubernetes環境変数を渡す場合には、Podテンプレートにenv, envFromを指定する。下記の5種類の情報源から環境偏するを埋め込むことが可能
    • 静的設定
    • Podの情報
    • コンテナの情報
    • Secretリソースの機密情報
    • ConfigMapリソースの設定値
  • 静的設定
    • spec.container.envに設定
  • Podの情報
    • どのノードで起動しているか、Pod自身のIPアドレス、起動時間などのPod情報はfieldRefで参照可能
    • 参照可能な値に関しては kubectl get pods -o yaml で確認可能
  • コンテナの情報
    • resourceFieldRefを使うことで参照することが可能
    • 参照可能な値に関しては kubectl get pods -o yaml で確認可能
    • spec.containers.name.env.valueFrom.resourceFieldRef
  • Secretリソースの機密情報
    • Secretリソースを利用する
  • ConfigMapリソースの設定値
    • 単純なKey-Value値や設定ファイルは ConfigMapで管理することが可能
    • 複数Podに重複がある場合に一括変換できるとかやりやすい
    • ConfigMapリソースで紹介
  • 環境変数利用時の注意点
    • 起動時の引き数に${}ではなく、$()を利用する
    • argsで参照可能なのはマニフェストファイル内のもののみもののみ
    • Entrypoint spec.containers.command をシェルスクリプトにして、シェルスクリプト内で処理をすることで変数を取得可能

7.3 Secret

  • ユーザー名やパスワードのような機密情報はどのようにコンテナに渡すのか?
    • Dockerビルド時にコンテナイメージに埋め込んでおく
      • コンテナイメージに書き込むことは可能だが、レジストリに機密情報が保存される、変更があるとイメージビルドをする必要があるなど結構たいへんです
    • PodやDeploymentのマニフェストに記載して渡す
      • マニフェストに機密情報が入ってしまうので管理が困難
      • 機密情報は別リソースに管理しておき、Podに読み込む。それがSecretリソース
      • Secretのマニフェストbase64エンコードされているが、暗号化されているわけではない。
      • Secretが定義されたマニフェスト暗号化するkubesecなどがある
  • Secretの分類
  • GenericタイプのSecret
    • スキーマレスの Secretを作る場合はタイプをgenericにする
    • 作成方法は4パターン
      • kubectlでファイルから値を作成して作成 —from-file
      • kubectlで envfileから値を参照して作成する —from-env-file
      • kubectlで直正値を渡して作成する —from-literal
      • マニフェストから作成する -f
    • kubectlでファイルから値を作成して作成
      • 改行コードをいれない
    • kubectl で envfile から値を参照して作成する
      • --from-env-file
      • でtxtをわたしてさくせい
    • kubectlで直正値を渡して作成する
      • --from-literal
      • もじをそのまま
    • マニフェストファイルの場合
  • TLSタイプのSecret
    • Ingressリソースから作成することが基本
    • 秘密鍵と証明書のファイルから作成
  • DockerレジストリタイプのSecret
    • プライベートリポジトリの場合、Dockerイメージ取得時には認証が必要
    • この認証情報をSecretとして指定して利用可能
    • kubectlから直接作成
    • イメージ取得時のSecretを利用
      • spec.imagePullSecrets
      • これは複数指定可能
  • Secretの利用
    • 大きく分けて下記の2パターンがあります
      • 環境変数を渡す
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
      • Volumeとしてマウントする
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
  • 環境変数として渡す
    • 環境変数として、secretkeyRefで参照可能
    • 動的なSecretの更新
      • Volumeマウントを利用したSecretでは一定期間ごとにkube-apiserverに変更クォ確認して変更がある場合はファイルの変更をおこなっている
    • kubesecのインストール
      • kubesecを利用することでSecretの暗号化がかのう
      • Google Cloud KMSを利用して暗号化可能
    • Secretは分散KVSのetcdで保存されている
    • etcdに保存されている

7.4 ConfigMap

  • Genericタイプのsecretと同じ方法で作成する
    • kubectlでファイル参照
    • kubectlで直接値を渡してさくせい
    • マニフェストから作成
  • kubectl でファイルから値を参照して作成する
    • --from-fileで作成する
    • ファイル名がKey名となる
    • --from-file=nginx.conf=sample-nginx.confとか
    • kubectl create configmap --save-config sample-configmap --from-file
  • 値を直接渡す
    • kubectl create configmap --save-config web-config --from-literal = connection.max = 100 --from-literal = connection.min = 10
  • マニフェストから作成する
  • ConfigMapを利用する
    • 大きく分けて下記の2パターンがあります
      • 環境変数を渡す
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
      • Volumeとしてマウントする
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
    • ほぼSecretと同じ

7.5 PersistentVolumeClaim

  • Volume, PersistentVolume, PersistentVolumeClameの違い
    • Volume
      • あらかじめ利用可能なボリュームをマニフェストに直接指定することで利用可能にするもの
      • 利用者がKubernetes上から新規でボリュームを作成したり、既存のボリュームを削除することはできない
    • PersistentVolume
      • 新規のボリュームの作成や、既存のボリュームの削除などを行うことが可能です。具体的には、マニフェストなどからPersistentVolumeリソースを別途作成する形になります。
    • PersistentVolumeClame
      • その名のとおり作成されたPersistentVolumeリソースの中からアサインするためのリソース
      • PersistentVolumeはクラスタにボリュームを登録するだけなので、実際にPodか ら利用するにはPersistentVolumeClaimを定義して利用する必要がある
      • Dynamic Provisioning機能を利用した場合は、PersistentVolumeClaimが利用されたタイミングでPersistentVolumeを動的に作成することが可能

7.6 Volume

  • 様々なpluginが存在。
  • Secret、ConfigMapもVolumeプラグインの一種
    • emptyDir
    • hostPath
    • downwardAPI
    • projected
    • nfs
    • iscsi
    • cephfs
  • Podに対して静的な領域に指定する形になるのでプラグインによっては競合に気をつけること
plugin
特徴
emptyDir
Terminateされると消える
ホスト上の任意の領域をマウントできるわけではない
hostPath
Node上の領域をコンテナにマッピングするプラグイン
ホスト上納任意の領域をマウントできる
typeには
  • Directory
  • DirectoryOrCreate
  • File
  • Socket
  • BlockDevice
から選択
セキュリティ的にはNG
terminateしても消えない
Podの/srv, ホストの/etcマウント
downwardAPI
fieldRef, resourceFieldRefで利用
Pod情報などをファイルとして配置する
projected
projectedは、Secret/ConfigMap/ downwardAPI/serviceAccountTokenのボリュームマウントを1箇所のディレクトリに集約するプラグイン

7.7 PersistentVolume (PV)

  • 永続化ボリュームとして整備
  • リソースとして個別に作成してから利用します。
  • PersistentVolumeの種類
    • ネットワーク越しにアタッチする
    • GCe Persistent DIsk
    • AWS Elastic Block Store
    • NFS
    • iSCSI
    • Ceph
    • Openstack Cinder
    • GlusterFS
  • PersistentVolumeの作成
    • 設定値
      • ラベル
      • 容量
      • アクセスモード
      • Reclaim Policy
      • マウントオプション
      • StorageClass
      • プラグインに特有の設定
    • ラベル
      • ラベルをつけないと、割当を行う際に目当てのボリュームを指定することが困難
      • type, speedとか
    • 容量
      • 3GBの容量を要求した場合は、一番近いものが選ばれる。差分は死ぬ?
    • アクセスモード
      • ReadWriteOnce RWO
        • 単一ノードからR/W
      • ReadOnlyMany ROM
        • 複数ノードからReadが可能
      • ReadWriteMany RWX
        • 複数ノードからRW
    • Reclaim Policy
      • 利用し終わった後の処理
        • Delete
        • Retain
        • Recycle
    • StorageClass
    • マウントオプション

7.8 PersistentVolumeClaim

  • PersistentVolumeを要求するリソース
  • 指定した条件にあった永続化ボリュームを割り当てる
  • PersistentVolumeClaimの設定
    • ラベルせレクタ
    • 容量
    • アクセスモード
    • Storageclass
  • 作成
  • Podからsの利用
    • spec.volumesにpersistentVolumeClaim.claimNameを指定
  • Dynamic Provisionning
    • StorageClassをリソースを作成。
    • Dynamic Provisioning用のStorageClassを指定してPersisitentVolumeClaimを作成する
    • GCEにおけるStorageClass
      • type
      • replication-type
      • zone
      • zones
  • ボリューム拡張
    • α版
    • PersistentVolumeClaimのリサイズを行うには事前にStorageClassにallowVolumeExpantion:trueを設定しておき、そのStorageClassを元にPersistentVolumeClaimを作成する必要があります。StorageClassは、下記のように定義します。
  • StatefulSetでのわーくろーど
    • spec.volumeClaimTemplateがStatefulSetには存在している。
    • かってにスケールする

7.9 volumeMountsで利用可能なオプション

  • ReadOnly
    • boolean
  • subPath
    • volumeMounts.subPathで指定

第8章 ClusterリソースとMetadataリソース

8.1 ClusterリソースとMetadataリソースの概要

  • Clusterリソースはクラスタの挙動を制御するためのリソース。下記10種類が利用可能
    • Node
    • Namespace
    • PersistentVolume
    • ResourceQuota
    • ServiceAccount
    • Role
    • ClusterRole
    • RoleBinding
    • ClusterRoleBinding
    • NetworkPolicy
  • Metadataリソースはクラスタ上にコンテナを起動させるのに利用するリソースです。4種類。
    • LimitRange
    • HorizontalPodAutoscaler
    • PodDisruptionBudget
    • CustomResourceDefinition

8.2 Node

  • Nodeを表示
    • kubectl get nodes -o wide
  • yaml形式
    • kubectl get nodes gke-k8s-default-pool-37a6668b-00bq -o yaml
  • 割当可能なリソース残量を確認するにはAllocatable から現在のリソースの使用量を差し引きするような必要があります。
  • リソース使用量を確認
    • kubectl describe node gke-k8s-default-pool-37a6668b-00bq 
  • k8sではNodeの状態を様々な側面から確認
  • Nodeのステータスがreadyかどうかはstatus.conditionsで確認可能
  • docker imageも確認可能
  • のーどのバージョン情報はstatus.nodeInfoに記載

8.3 Namespace

  • 仮想的なクラスタの分離機能
  • 初期状態では下記の3つ
    • default
    • kube-system
    • kube-public
  • 自分で作成することも可能
    • リソースのクォータを設定するresourceQuota
    • 認証を行うRBAC

8.4 まとめ

  • NodeとNamespaceは重要だゾ!

第9章 リソース管理とオートスケーリング

9.1 リソースの制限

  • リソース制限は必須
  • CPUは周波数による指定ではなく1 vCPUを1000millicoresとする単位で指定する。
  • リソース種別
    • CPU:1 = 1000m = 1 vCPU
  • メモリ
    • 1G = 1000M (1Gi = 1024 Mi)
  • Requestは下限
  • Lmitsは上限
  • kubectl get nodes -o yaml ではノードの反りソース料と割当可能リソース量のみ
  • kubectl describe nodeを利用する必要がある
  • GPUなどのリソース制限
  • オーバーコミットとリソース不足
    • リソース不足の量までスケールしても動かない
    • それはそう

9.2 Cluster Autoscalerとリソース不足

  • Kubernetesでは食らうsた自体をオートスケールする機能がある
  • 需要に応じてNodeを自動追加していく
  • Pending状態のPodができたタイミングで初めてCluster Autoscalerが起動する
    • RequestとLimitを適切に設定しないと逼迫時にスケールしなかったり、平穏時にスケールしたりする
      • Request(最低限要求)が高すぎると、新規ノード払い出しがひつようになったりする
      • Requestを低くしすぎてもだめ。低すぎると各PODのリソースを食らいつくすが、requestsで設定している量が小さいためノードのリソース状況に余裕があるように見えるため
  • 心がけること
    • RequestsとLimitsに顕著な差をつけないこと
    • Requestsを大きくしすぎないこと

9.3 LimitRangeによるリソース制限

  • LimitRangeはNameSpaceごとに制限をかける
  • 設定可能な項目
    • default
      • デフォルトのLimits
    • defaultRequest
      • デフォルトのRequests
    • max
      • 最大リソース
    • min
      • 最小リソース
    • maxLimitRequestRatio
      • Limit/Requestsの割合
  • LimitRangeを設定可能なリソースは下記の3種類
    • Pod
    • Container
    • PersistentVolumeClaim
  • 一つのLimitRangeで複数のTypeに制限をかけることも可能
  • デフォルトで作成されているLimitRange
    • Requestsすら指定していない場合は、スケジューラは永遠にそのノードにスケジュールし続ける
    • GKEではデフォルトで設定されている
      • kubectl get limitranges limits -o yaml
    • 消すとき
      • kubectl delete limitranges --all
  • Containerに対するLimitRange
    • 設定後に下記コマンドでコンテナの状況をみると反映されていることがわかる
      • kubectl get pods sample-pod -o json | jq .spec.containers.resources
    • こえるリソース、不足したリソースを指定するとエラーになる
      • Error from server (Forbidden): error when creating "sample-pod-upper.yaml": pods "sample-pod-upper" is forbidden: maximum memory usage per Container is 1Gi, but limit is 2Gi
  • Podに対するLimitRange
  • PersistentVolumeClaimに対するLimitRange

9.4 QoS Class

  • Pod には Request/Limits の設定に応じて自動的に QoS Class の値が設定される
  • 自分が設定するものではなく自動で設定されるもの
    •  Best Effort:3
      • どちらも未指定
    • Guaranteed:1
      • Requests/Limits が同じでCPUとメモリの両方が指定されている
    • Burstable:2
      • Guranteedがみたされず、1つ以上のRequests/Limitsが設定されている
  • 上の順序でPodが停止される
  • QoS Class は Pod の status.qosClassで確認することが可能
  • 下記コマンドで確認可能
    • kubectl get pods -o custom-columns="NAME:{.metadata.name}, QoS Class:{.status.qosClass}"

9.5 ResourceQuotaによるNamespaceのリソースクォータ制

  • Namespace = 仮想k8sクラスタ
  • Namespaceごとの
    • 作成可能なリソース数
    • リソース使用量の制限
  • 作成可能なリソース宇野制限
    • count/RESOURCE.GROUP
    • この記法を用いてクォータの制限をかけることが可能になった
  • リソース使用量の制限
    • Storageに関してはlimitsは存在しない

9.6 HorizontalPodAutoscaler (HPA)

  • Deplouyment, ReplicaSet, ReplicationControllerのレプリカ数をCPU不可に応じて自動スケールするリソース
  • 必要なレプリカ数 = ceil(sum(Podの現在のCPU利用率)/targetAverageUtilization)
  • CPU使用率は各Podの1分間の平均値
  • スケールアウトの条件式
    • avg(Podの現在のCPU使用率) / targetAverageUtilization > 1.1
  • スケールインの条件式
    • avg(Podの現在のCPU使用率) / targetAverageUtilization < 0.9
  • 別途prometheusなどの監視ツールと連携することが可能

9.7 VerticalPodAutoscaler (VPA)

  • コンテナに割り当てるリソースを自動的にスケールさせる
  • スケールアップ。垂直スケーリング。

第10章 ヘルスチェックとコンテナライフサイクル

10.1 ヘルスチェック

  • spec.restartPolicyに従ってPodの再起動を行う
  • その他にも詳細な設定を実施することが可能
  • Liveness Probe と Readiness Probe 2出位のヘルスチェック機構
    • 設定内容は全く同じ
    • spec.containersに設定する
種類
役割
失敗時の挙動
Liveness Probe
Podが正常に動作しているかの確認
(プロセスにバグが有った場合などに再起動できるように)
Pod の再起動
Readiness Probe
Podがサービスインできる準備ができているかの確認
トラフィックを流さない
  • 通常のロードバランサからのNode へのヘルスチェックはICMPによる簡易チェックのみ。Podの状態をチェックする場合は上記のProbe機構を利用する必要がある
    • Internet Control Massage Protocol
  • 三種類のヘルスチェック方式
    • ともに3種類のチェック方式を利用可能
      • exec
        • コンテナを実行し、Exitコードが0でなければ失敗
        • コマンドを指定しておく
      • httpGet
        • HTTP GET リクエストを実行し、ステータスが2xx, 3xxでなければ失敗
        • パスやポートを指定して、ホスト、ヘッダーとかも指定
      • tcpSocket
        • TCPセッションが確立できなければ失敗
        • ポートを指定
  • ヘルスチェックの間隔
    • 設定項目は5つ
      • initialDelaySeconds
        • 初回ヘルスチェック開始までの遅延
      • periodSeconds
        • ヘルスチェック間隔
      • timeoutSeconds
      • successThreshold
        • 成功と判断するまでのチェック回数
      • failureThreshold
        • 失敗と(ry
  • ヘルスチェックの作成
  • Liveness Probeの失敗
$ kubectl get pods sample-liveness --watch
NAME              READY   STATUS    RESTARTS   AGE
sample-liveness   1/1     Running   1          71s
sample-liveness   1/1     Running   2          2m33s
sample-liveness   0/1     CrashLoopBackOff   2          2m43s
sample-liveness   1/1     Running            3          2m58s
    • kubectl describeで詳細を確認可能
kubectl get pods sample-readiness --watch
NAME               READY   STATUS    RESTARTS   AGE
sample-readiness   1/1     Running   0          19m
sample-readiness   0/1     Running   0          19m
sample-readiness   1/1     Running   0          20m

10.2 コンテナのライフサイクルと再始動 (restartPolicy)

10.3 Init Containers

  • Pod内でメインコンテナを起動する前に別のコンテナを起動するための機能。
  • セットアップ用のスクリプトなどをコンテナに含まずにやれる
  • spec.initContainers.commnad
    • 複数選択可能
    • spec.containers よりはやく実行される
  • 利用シーン
    • リポジトリからファイルなどを取得する処理
    • コンテナの起動を遅延させる処理
    • 設定ファイルを動的に生成する処理
    • Serviceが作成されているかの確認
    • その他メインコンテナを起動する前のチェック作業
  • https://github.com/Rtaro02/studyk8s/blob/master/sample-initcontainer.yaml
  • initConatainersの順序性は担保される

10.4 起動時と終了時に任意のコマンドを実行する (postStart/preStop)

10.5 Podの安全な停止とタイミング

  • Podの削除には何段階かに渡って処理が実行されている
  • 起動中のPodの削除要求がAPIサーバーに届くと、非同期に
    • preStop処理+SIGTERM処理
    • Serviceからの除外設定
  • が実行される
  • リクエスト断が発生する可能性がある。これをなくすには
    • preStop処理+SIGTERM処理で待機
    • preStop処理+SIGTERM処理でリクエストを受けつつ停止処理を行う
  • spec.termination.GracePeriodSeconds という設定値以内にpreStop + SIGTERMを終了させる必要がある

10.6 リソースを削除したときの挙動

  • 親リソースさくじょされたばあいには、小リソースなども削除するためのガベージコレクションが発生する
  • PodにはどのResplicaSetから作成されたかを判別するために、自動的に情報が保存されている
$ kubectl get pods sample-rs-55zmv -o json | jq .metadata.ownerReferences
[
  {
    "apiVersion": "apps/v1",
    "blockOwnerDeletion": true,
    "controller": true,
    "kind": "ReplicaSet",
    "name": "sample-rs",
    "uid": "f0ee7ed8-a857-4c4e-b2b0-db6ffa5fb759"
  }
]
  • ReplicaSetを削除したときの挙動
  • backとforeはカスケーゾ削除と呼ばれている(結果的に依存するPodの削除を行うため)
    • Background (Default)
      • ReplicaSet: 直ちに削除
      • Pod: ガベージコレクタ、バックグラウンドで非同期に削除
    • Foreground
      • ReplicaSet: 直ちに削除しない、設定する
      • Pod: ガベージコレクタがフラグ立てたものだけを削除。falseはバックグラウンド処理で削除
      • すべて終わったらReplicaSetを削除する
    • Orphan
      • ReplicaSet削除時にPodの削除を実施しない
  • 現状はForegroundはなし
  • Backgroudで消したい場合は
    • kubectl delete --cascade=true replicaset sample-rs
  • カスケードオプションをfalseにすればPodを残したままReplicaSetを削除することが可能

第11章 メンテナンスとノードの停止

  • ノード停止時にはPod停止が必要
  • SIGTERM, SIGKILLのシグナルに対応したアプリケーションを作成する必要がある

11.2 スケジューリング対象からの除外と復帰

  • ノードは下記のステータスを持つ
    • SchedulingEnabled
    • SchdulingDisabled
  • SchdulingDisabled になったノードはスケジューリング対象から外れ、ノード上でPodが新規作成されなくなります。
  • Disableにするには
    • kubectl cordon
  • Endleにするには
    • kubectl uncordon

11.3 ノードの排出処理によるPod退避 (drain)

  • ステータスをDisabledにしてもPodは動き続ける
  • 排出処理がkubectl drainコマンド
  • --forceオプション
    • deploymentなどで管理されていない単体のPodを削除する場合
  • --delete-local-data
    • local storageを使っているPodを削除しようとした場合
  • --ignore-daemonsets
    • デーモンセットが管理しているPod

11.4 PodDisruptionBudget(PDB)による安全な退避

  • PodDisruptionBudgetはノードが排出処理を行う際に、Podを停止することができる最大数を設定するリソース。
  • 全部停止しちゃうとダウンタイムが発生する可能性がある
  • 最小の起動数と、最大の停止数を設定
  • 教科書どおりやったら、両方設定できなかった!
  • パーセンテージでの対応も可能

第12章 高度で柔軟なスケジューリング

12.1 高度なスケジューリングとAffinity/Anti-Affinity

  • スケジューリングもNodeやPodのラベルを使うことで実現
  • スケジューリングには下記がある
    • Podのスケジューリング時に特定のNodeを指定する方法
    • Nodeに対して汚れ(tiant)をつけておき、それを許容(Tolerations)できうPodのみスケジューリングを許可する方法
  • スケジューリングで起動する方法
    • nodeSelector
      • 簡易的なNode Affinity機能
    • Node Affinity
      • 特定のノード上だけで実行する
    • Node Anti-Affinity
      • 特定のノード以外で実行する
    • Inter-Pod Affinity
    • Inter-Pod Anti-Affinity

12.2 ビルトインノードラベルとラベルの追加

12.3 nodeSelector (Simplest Node Affinity)

12.4 Node Affinity

  • Podを特定のノード上へスケジュールするポリシー
  • spec.affinity.nodeAffinityに設定
  • requiredDuringSchedulingIgnoredDuringExecution
    • 必須のスケジューリングポリシー
  • preferredDuringSchedulingIgnoredDuringExecution
    • 優先的に考慮されるスケジューリングポリシー
  • kubectl -L=disktype,cputype,disksize get node
  • 優先条件を満たせばそこのノードにスケジューリングされる
  • 優先条件満たしていても、Nodeが停止状態の場合には必須条件を満たしたノードへスケジューリングされる
  • 必須条件を満たせない場合はスケジューリングに失敗する
  • 必須条件
    • nodeSelectorTerms配列
      • 複数指定可能
      • OR条件
      • matchExpressions配下はAnd条件
  • 優先条件
    • preferredDuringSchedulingIgnoredDuringExecution配列
      • 複数指定可能
      • それぞれスケジューリングされるが、Weightで指定した量で分配される
      • matchExpressions配下はAND条件

12.5 matchExpressionsのオペレータとset-based条件

  • keyで指定したラベル名、オペレータで一致するものを指定、valueで値を指定
  • 利用可能なオペレータ
    • In
      • いずれかと一致
    • NotIn
      • どれにも一致しない
    • Exists
      • ラベルが存在すればOK
    • DoesNotExists
      • ラベルAが存在しない
    • Gt
      • 値が指定したものより大きい
    • Lt
      • 値が指定したものより小さい

12.6 Node Anti-Affinity

  • 特定のノード以外にスケジューリングするポリシー
  • 厳密には存在しない
  • spec.affinity.nodeAffinityの条件部分に否定形のオペレータを指定することで実現

12.7 Inter-Pod Affinity

  • 特定のPodが実行されているドメイン上へのPodをスケジューリングするポリシー
  • spec.affinity.podAffinityを指定
  • Pod同士を近づけて配置することができるので、Pod間のレイテンシを下げることが可能
  • topologyKeyでどのドメインをスケジューリング対象にするかを指定する
    • sample-appのラベルに一致するPodと同じノード上にスケジューリングする
  • failure-domain.beta.kubernetes.io/zoneにした場合は同じゾーンにスケジューリングする
  • 必須と優先を設定可能
  • スケジューラーは配置を制御するだけ

12.8 Inter-Pod Anti-Affinity

  • 特定のPodがいないドメイン上で動作させるポリシー
  • spec.affinity.podAntiAffinityに設定可能

12.9 複数の条件を組み合わせたPodのスケジューリング

12.10 TaintsとTolerations

  • 汚れTaintsをつけてそれを許容できるかどうかでデプロイする
  • 条件に合致しない場合にはあとからもそのPodを排除することができるようになった
  • 設定方法
  • 下記で設定
    • kubectl tiant
  • Key, Valueは任意
  • 設定できるEffect
    • PreferNoSchedule
      • 可能な限りスケジューリングしない
      • 条件にマッチしなくても、他に配置可能なノードがない場合はスケジューリング候補になる
    • NoSchedule
      • スケジューリングしない
      • すでにスケジューリングされているPodはそのまま
      • 条件にマッチしない場合はスケジューリングを許可しない
    • NoExecute
      • 実行を許可しない
      • すでにスケジューリングされているPodは停止
      • 条件にマッチしない場合はスケジューリングもせず、起動済みPodも停止する
  • Torerationを指定したPodの起動
    • PodのTorerationsはspec.tolerationsで指定する
    • オペレータの種類
      • Equal
      • Exists
        • keyが存在する
    • 未指定の場合はすべてのノードにスケジューリングされる
  • NoExecuteの一定時間の許容
    • 一定時間だけ許容する
    • spec.tolerations.tolerationsSecondsで指定
  • 複数のTaintとTolerations
    • 複数指定も可能だが、全て満たさないといけないことに注意

12.11 PriorityClassによるPodの優先度と退避

  • 優先スケジューリング
  • valueの値によって優先順位がきまる
  • globalDefaultはpriorityClassが指定されていない場合のデフォルト設定となる
  • 複数ある場合は優先順位が低いものがデフォルト
  • 退避の際には、、、
    • Affinituなどのスケジューリング機能が満たされるかどうかを判断する
    • InterPodAffinityと連携すると、優先度低によりPodが退避されてそれによりスケジューリング対象外になる可能性があるので注意

12.12 その他スケジューリング

  • 独自スケジューラーを作成することも可能

第13章セキュリティ

13.1 ServiceAccount

  • UserAccount, ServiceAccountがある
  • UserAccount
    • GKEはGCPアカウントとリンクしている。
    • クラスタレベルの管理
  • ServiceAccount
    • k8sの世界
    • Pod起動時には1つわりあてられる
    • 指定しない場合はデフォルトが割当られる
  • ServiceAccountの作成
    • コマンドで作成
      • kubectl create serviceaccount sample-servicesaccount
    • SecretであるimagePullSecretsを設定する場合はkubectl patchもしくはマニフェスト
    • 作成時には指定しなかったsecrets という項目の存在。自動的に作成される。
    • sample-serviceaccount-token-46d24 ってかんじで。
    • このtokenを利用してkubernetes apiへの認証情報として利用することが可能
    • Podに割り当てたServiceAccoutに割り当ててある権限がそのままPodに割り当てる権限となる
    • Podに割り当てる場合はsepc.serviceAccountNameを指定
    • 下記に証明書などがおいてある
      • kubectl exec -it sample-serviceaccount-pod -- ls /var/run/secrets/kubernetes.io/serviceaccount/
  • トークンの自動マウント
    • トークンの自動マウントを無効化することも可能
    • automountServiceAccountTokenをfalseに設定する
    • Podでも設定可能
    • 両方で設定されている場合はPodの設定が優先される
    • クライアントライブラリと認証
      • ServiceAccountのトークンを利用する場合 (In-ClusterConfig)
    • kubeconfigの認証情報を指定する場合
  • Dockerレジストリ認証情報の自動設定

13.2 RBAC (Role Based Access Control)

  • どういった操作を許可するのかを定めたRoleを作成し、ServiceAccountなどのUserに対してRoleを紐付けることで権限を管理する
  • Role / RoleBinding / User
  • RBACには
    • RoleBinding
    • ClusterRoleBinding
  • RoleとClusterRole
    • プリセットで用意されているClusterRole
      • cluster-admin
        • すべてのリソースを管理可能
      • admin
        • ClusterRoleの編集+NamespaceレベルのRBAC
      • edit
        • ReadWrite
      • view
        • ReadOnly
    • Role作成時にはrules.verbで指定する
      • *
        • すべての処理
      • create
      • delete
      • get
      • list
      • patch
        • 一部変更
      • update
      • watch
        • 変更の追従
    • Role
      • RoleはNamespaceを指定して作成する
        • apiGroupが複数あるという点
        • すべてのDeploymentリソースを対象としてRoleを作成する場合はapiGroupsには注意して下さい
      • deploymentとdeployment/scaleのリソースがある。desployment/scaleがない場合には、scalingの処理を行うことができない
    • ClusterRoleの作成
      • nonResourceURLsはへるちぇとか
    • ClusterRoleのAggregation
      • aggregationRule.clusterRoleSelectors.matchLabelsで設定したsub-clusterroleを設定可能
      • sub-roleをルールを削除すると反映される
  • RoleBindingとClusterRoleBinding
    • 構成はClusterRoleBindingとほぼ同じ
    • RoleBindingの作成
    • Deploymentが許されているもののみ実行可能
    • deployment/scaleまでやっていればdeploymentのスケールが可能
    • replicasetのscaleはできない

13.3 SecurityContext

  • ここのコンテナに対するセキュリティ設定
    • privileged
      • 特権
    • capabilities
      • ケイパビリティの追加と削除
    • allowPrivilegeEscalation
      • コンテナ実行時に親プロセス以上の権限を与えるかどうか
    • readOnlyRootFilesystem
      • rootファイルをリードオンリーにするかどうか
    • runAsUser
    • runAsGroup
    • runAsNonRoot
    • seLinuxOptions
  • 特権コンテナの作成
    • spec.containers.securityContext.privilegedをtrueにする
  • capabilitiesの付与
    • 特権コンテナではホストと同等のCapabiltyが追加されるが、細かくコンテナに付与、剥奪できる
  • rootファイルシステムのReadOnly化
    • コンテナイメージに含まれているファイルをReadOnlyにすることが可能

13.4 PodSecurityContext

  • Podに対すセキュリティ設定
    • runAsUser
    • runAsGroup
    • runAsNonRoot
    • supplementalGroups
      • プライマリGIDに追加で付与するGIDのリストを指定
    • fsGroups
    • sysctls
    • seLinuxOptions
  • 実行ユーザーの変更
    • Entrypointの実行ユーザーの変更行うことが可能
  • rootユーザーでの実行制限
    • nginxのようなroot要求のコマンドは失敗する
  • ファイルシステムのグループ設定
    • マウントしたVolumeはroot:rootになる
    • 実行ユーザー変更したときに権限がない場合があるので、ファイルシステムのグループ設定を実施する
  • sysctlによるカーネルパラメータの設定
    • カーネルパラメータはPod内のコンテナで共有
    • safe と unsafe に分類

13.5 PodSecurityPolicy

13.6 NetworkPolicy

13.7 認証/認可とAdmission Control

  • APIサーバーにリクエスト制御を追加
  • Authentication/AuthN 認証
  • Ahthentication/AuthZ 認可

13.8 PodPreset

  • デフォルト値を入れる
  • ラベルにマッチするpodにデフォルトの定義を入れる
  • Podpresetの内容はPodの個別定義で書き換えされないので注意

第14章 マニフェストの汎用化を行うオープンソースソフトウェア

14.1 マニフェストの汎用化

  • k8sではyamlファイルを書いてkubectlで管理
  • 大規模になればなるほどしんどくなる
  • マニフェストの汎用化という処理が必要になってくる

14.2 Helm

  • kubernetesのパッケージマネージャ
  • パッケージ = Chart
  • tiller podを利用する
  • 基本的にはstableのChartのみが影響
  • incubatorのリポジトリを手動で追加が必要
  • リポジトリ更新
    • helm repo update
  • リポジトリ検索
    • helm search data
  • 詳細情報
    • helm inspect stable/datadog
  • インストール
    • helm install xxxx
  • valueファイル
    • ファイルをりようしてインストール
    • helm install xxxx --value values.yaml
  • 独自のChartもつくれる

14.3 Ksonnet

  • JSONベース
  • コンセプト
    • Prototype
      • Componentのもととなるひながた
    • Component
      • Prototypeに対してパラメータを指定して具体化した実体
    • Application
      • 複数のComponentから成り立つアプリケーション
    • Environment
  • 複数のKubernetes環境に同じアプリケーションをデプロイすることを目的としている

第15章 モニタリング

15.1 Kubernetesにおける監視

  • Datadog, Prometheus

15.2 Datadog

  • DaemonsetでAgentを各ノード上に起動する
  • kube-state-merticsを追加でインストール連携が推奨

15.3 Prometheus

  • CNCFがホストしているもの
  • 下記で構成
    • Prometheus Server
      • Alert Manager
      • Exporter
      • Push Gateway

第16章 コンテナログの収集

16.1 コンテナ上のアプリケーションログの出力

  • クラスタ外部にログを転送
  • アプリケーションが特定ンのファイルにログを書き出す
  • アプリケーションからライブラリを使って直接外部に転送する
  • ログ欠損が内ように永続化領域に保存しよう

16.2 Fluentdによるログ集約

  • DaemonSetを利用してPodを起動する
  • 起動するだけで転送可能なので、疎結合でいける
  • Fluentbitってのもある。IoT向けだけど、軽量なのでfluentdに利用可能

16.3 Datadog Logsによるログ集約

  • Datadogと合わせて収集可能

第17章 Kubernetes環境でのCI/CD

17.1 Kubernetes環境でのCI/CD

17.2 Spinnaker

17.3 Skaffold

  • コンテナイメージのビルド
  • コンテナイメージのプッシュ
  • Kubernetesへのデプロイ

17.4 JenkisX

17.5 GitOps

第18章 マイクロサービスアーキテクチャとサービスメッシュ

18.1 マイクロサービスアーキテクチャとは

  • 適切に分割する困難さ
  • モニタリングが難しい

18.2 サービスメッシュ

  • よくあるやつ
    • Istio
    • Conduit
    • Linkerd
  • Pod間の通信経路にプロキシを挟むことでトラフィックのモニタリングやコントールする
  • Traffic shifting
    • 99%を古いDeploymentへ
    • 1%を新しいDeploymentへ
    • カナリアリリース
  • Circuit Breaker
    • 転送元の障害が発生したときに止めるのがサーキットブレイカ
  • Fault Injection
    • 意図的にリクエストを遅延させたり失敗させたりする
    • 失敗時に適切に起動するかをみる
  • Rate Limit
    • リクエスト制限
    • e.g.) 10000 requests/second
  • Retry
    • アプリケーションでやらなくてもリトライ処理をやってくれる

18.3 Linkerd

  • App A, App B, AppBの例
    • A → B → Cに流れる
    • l5dを各Nodeに立ち上げておく
      • イン・アウトともにl5d経由でリクエストする
      • 下記の流れ
        • l5d A
        • App a
        • l5d a
        • l5d b
        • app b
        • l5d b
        • l5d c
        • app c
    • トラフィックコントロールを行うには namerdを利用する動的に設定が可能

18.4 Conduit (Linkerd v2)

18.5 Istio

第19章 Kubernetesアーキテクチャを知る

  • 7つのコンポーネントからなる
    • etcd
    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • kube-proxy
    • kube-dns

19.2 etcd

  • etcdはGo言語で記述された設定情報の共有とサービス検出のための分散KVS
  • etcdのデータを守ることが最も大切
  • クラスタ化するほうがよい
  • 奇数台にしたほうがよい

19.3 kube-apiserver

  • kubectlの対向
  • kube-apiserverはPodリソースの情報をetcdに書き込む。
  • このときには起動ノード情報は決まっていない
  • kube-schedulerがapi経由で書き込みすることでノードがきまる
  • kubeletがノード情報が自身に割り当てられている起動していないPodがあれば起動する
  • apiserverを中心にやっている

19.4 kube-sheduler

  • Nodeのステータス、Affinity情報をもとに起動ノードを決定する

19.5 kube-controller-manager

  • Podを登録する
  • 実際のスケジューリングはschedulerが実施

19.6 kubelet

  • dockerなどのコンテナランタイムと連携してこんてなの起動停止を実施
  • つかえるの
    • docker-shim
    • containerd
    • cri-o
    • Frakti
    • rktlet

19.7 kube-proxy

  • 転送方式
    • ユーザースペースで処理
    • iptablesで処理
    • IPVSで処理

19.8 kube-dns

19.9 その他コンポーネント

19.10 CustomResourceDefinitionとOperator

  • 独自リソースを拡張することができる

第20章 kubernetesとこれから

20.1 取り巻く標準化

  • OCI (Open Container Initiative)
    • コンテナの標準仕様
  • CRI (Container Runtime Interface)
    • k8sとコンテナランタイムをつなぐインターフェース
  • CSI (Container Storage Interface)
  • CNI (Container Network Interface)
    • ネットワークインターフェース
      • Project Calico
      • Cilium

20.2 Kubernetesとエコシステム

  • ミドルウェアk8s対応、周辺のエコシステムができてきた
  • k8sクラスタ上に展開するXaaS
    • Vitess
      • MySQL環境をデプロイ
    • NATS
      • メッセージキュー環境をデプロイ
    • Rook
      • Cephなどの分散ストレージ環境尾をデプロイ
    • Kubeflow
  • Serverless
    • OpennFaas
    • Kubeless
    • Fission
    • Knative
  • Service Broker, Service Catalog
 

SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム

 

1章 イントロダクション

1.1 サービス管理へのシステム管理者のアプローチ

  • 開発・運用の分断
    • 直接コスト
      • 変更管理やイベント処理を手作業に頼るチームがサービス稼働させる場合、サービスの変更やスケールに伴いコストがかさむ。
      • サービス増大に応じてチームを大きくしていく必要がある
    • 間接コスト
      • 2つのチームのバックグラウンド、スキルセット、動機づけが異なることから発生するもの
  • ローンチを減らして
    • フラグの変更
    • インクリメンタルなアップデート
    • チェリーピック
  • を増やすようになる
  • ローンチレビューをへらすためにプロダクトの分割といった戦略を取るようになる

1.2 サービス管理へのGoogleのアプローチ:サイトリライアビリティエンジニアリング

  • ソフトウェアエンジニアリングを活用する
  • シスアドによってしばしば手作業で行われたであろう作業を遂行するシステムを構築する
  • SREとは
    • ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの
  • SREは2つのカテゴリにわけられる
    • 50%
      • Googleおソフトウェアエンジニア
    • 50%
      • スキルセットを満たしたエンジニアの候補者
  • 手作業でタスクをこなすことにすぎに飽きてしまい
  • それまでの作業を複座腕も代替してくれるソフトウェアに書く
  • Googleでは
    • チケット、オンコール、手作業などの「運用」業務の合計を50%以下にする
    • これらは上限。開発に注力できるようになる
    • 計測が必要
  • 課題はSREの採用

1.3 SREの心情

  • SREは下記に責任を追う
    • サービスの可用性
    • レイテンシ
    • パフォーーマンス
    • 効率性
    • 変更管理
    • モニタリング
    • 緊急対応
    • キャパシティプランニング
  • エンジニアリングへの継続的な注力の保証
    • プロダクトの増大に伴うう運用コストの増大を生じさせない
    • 2つが対応可能な最大オンコールイベント
    • ポストモーテムはインシデントに対して書きましょう
  • サービスのSLOを下回ることなく、変更の速度の最大化を追求する
    • エラーバジェットの導入によって解決した
      • 100%を信頼性の目標にすることは、基本的にはいかなる場合にも間違っている
    • 99.999% と 100%の違いは不安定のノイズにまぎれてしまい、その0.001%の向上はあまり意味をなさない
    • 考慮にいれるべきことお
      • プロダクトの利用方法を踏まえて考えたとき、ユーザーが満足する可用性のレベルはどの程度か
      • プロダクトの可用性に満足できなかったユーザーにとって、どのような大対策があるか
      • 可用性のレベルを変更したとして、ユーザーのプロダクトの利用の仕方に何が起こるか
    • 100%と99.99%の間にある0.01%がエラーバジェット。これをこえない限り、なんにでも利用可能
    • サービス障害の発生を恐れるのではなくこれをコントロールすることが大事
  • モニタリング
    • メール発報系のモニタリングは問題ある(人間がアクションを検討する必要があるので)
    • ソフトウェアが解釈を行い、人間がアクションが必要なときのみ通知を受け取るようになっているべき
    • アラート
      • 即座のアクションが必要
    • チケット
      • 人間のアクションが必要。だが、即時性はない
    • ロギング
      • 人間がみる必要がないもの
  • 緊急対応
    • 信頼性は平均故障時間MTTFと平均修復時間MTTRの関数
    • 「不運の輪」
  • 変更管理
    • 70%のサービス障害は動作中のシステムの変更によって生じている
    • この領域でのベストプラクティスは自動化によって
      • 全身的なロールアウトの実装
      • 高速かつ正確な問題の検出
      • 問題が生じた歳の安全なロールバック
  • 需要の予測とキャパシティプランニング
    • いくつかのステップが必須
      • 自然な需要の正確な予測
      • 需要予測に突発的な需要の発生源を正確に織り込むこと
      • 計算リソースのキャパシティとサービスのんキャパシティの関連を把握するための定期的なシステムの負荷テスト
  • プロビジョニング
    • 注意が必要
  • 効率とパフォーマンス
    • キャパシティ、プロビジョニング、モニタリングが大事

第二章 SREの観点なから見たGoogleのプロダクション環境

  • ハードウェア
    • Googleのマシンリソースはほぼデータセンターにある
      • マシン:1つのハードウェア、VM
      • サーバー:サービスを実装しているソフトウェア
    • Borg
    • サーバー
  • ハードウェアを組織化するシステムソフトウェア
    • 1つクラスタでは1年で数千のマシン障害が発生している

第三章 リスクの受容

  • 過度の信頼性はコストにかえる

3.1 リスクの管理

  • 冗長なマシン/コンピュートリソースのコスト
  • 機会のコスト
  • 私たちのゴールは、サービスの取るリスクと、そのビジネスが許容できるリスクの歩調を意識的に 合わせることです。

3.2 サービスリスクの計測

  • 最適化したいシステムの特徴を示す客観的なメトリクスを見い出す
  • 計画外の停止時間
    • サービスの可用性に求められるレベル
    • 時間のメトリクス
      • 99.99% → 52.56分以内のダウンタイム
      • Googleでは時間を用いたメトリクスはあまり意味を持たない
    • リクエスト成功率というメトリクス
      • 可用性=(成功したリクエスト数)/ (総リクエスト数)
      • 99.99% → 250万リクエスト処理、エラー回数250回

3.3 サービスのリスク許容度

  • SREがプロダクトマネージャーと共同で作業を行い、一連のビジネスゴールをエンジニアリング可能な明確な目標に変換する必要がある

3.4 エラーバジェットの活用

  • SREはサービスの信頼性をもとにして評価される。
    • これは変更の頻度を高めることとは反対の方向にインセンティブが生じる
    • SREにとってはプロダクトの全体的な状態に目が行く
  • 一方で開発チームはプロダクトをいかに開発の速度を上げるかで評価される
  • 両者の間には緊張感が発生する
    • ソフトウェア障害の許容度
    • テスト
    • プッシュの頻度
    • カナリアテストの期間と規模
      • ワークロードの一部を使ってテストをすることがベストプラクティス
  • DevとSREが協力して、SLOに基づくエラーバジェットを定義する
    • Googleのやりかた
      • PdMがSLOを規定する。期待の稼働時間
      • モニタリングシステムによって計測
      • この差分が損失可能な信頼性という予算の残分
      • 計測された稼働時間がSLOを超えている = エラーバジェットが残っているなら新シリリースをプッシュできる
  • エラーバジェットの主なメリット
    • DevとSREが共通のインセンティブを提供し、両者がイノベーションと信頼性の適切なバランスを見出すことに中止できる
    • エラーバジェットを使い切りそうならリリース頻度を下げる
    • Devは速度あげたい、SREはそれに反対している場合はエラーバジェットは良いガイドになってくれる
    • SLOを緩めることでイノベーションを優先することも可能

重要な知見

  • サービスの信頼性管理の大部分はリスク管理に関係することであり、リスク管理には多くのコストが掛かることがあります。
  • 信頼性のターゲットとして100%が適切であることはほぼない。
    • 達成できない
    • サービスのユーザーが求める/認識できるレベルでもない
  • エラーバジェット
    • SREとプロダクト開発者との間でインセンティブを一致させる
    • リリース頻度の判断

4章 サービスレベル目標

  • Service Level Agreements
  • Service Level Objectives
  • Service Level Indicators

4.1 サービスレベルに関する用語

  • 指標
  • 目標
    • SLO
      • 基本的なSLIとの関係は下記の通り
        • SLI <= ターゲット
        • 下限 <= SLI <= 上限
      • QPS
      • ユーザーに対してどうみせるか?設定しないと過剰な信頼や信頼の損失を招きかねない。
    • Chubby
      • 過剰な信頼があり、依存するサービスが落ちないことを前提としていたので計画的なサービス停止を実施するようになった。
  • アグリーメント
    • SLA
      • SLAはユーザーとのアグリーメント
      • SLOとの違いはそれが満たされなかった場合にどうなるかが明確に定義されているかどうか
      • SLAはビジネスに密接に関わるもの
      • SLAなくともSLOやSLIは設定しようね

4.2 指標の実際

  • サービス提供者とユーザーの関心事
    • SLIは慎重に選びましょう
    • ユーザーとやり取りするサーバーシステム
    • ストレージシステム
      • レイテンシ
      • 可用性
      • 耐久性(データが失われない)
    • ビッグデータシステム
    • 正確性
      • データが正確であること
      • これはすべてのシステムでやるべき
  • 指標の収集
    • 通常はサーバーサイドで収集するがクライアントサイドで収集が必要な場合もある
      • Javescriptの問題でユーザー体感のレイテンシが低下している可能性もある
    • 集計
      • 殆どのメトリクスは平均よりも分布として考えるほうが良さそう。平均だけでは気づけない
      • パーセンタイル使おうな
      • 人はリクエスト病がばらつくぐらいなら、ちょっと遅いぐらいのほうが好きらしい
  • 指標値の標準化
    • 定義を標準化しておくことが良さそう。標準に従うものはそれでよい。
      • 集計のインターバル:「集計期間は1分とする」
      • 集計の対象領域:「クラスタ内のすべてのタスク」
      • 計測の頻度:「10秒ごと」
      • 対象となるリクエスト:「ブラックボックスモニタリングジョブからのHTTP GET」
      • データの取得方法:「モニタリングシステムを通じて、サーバーで計測」
      • データアクセスのレイテンシ:「最後のバイトまでの時間」

4.3 目標の実際

  • 目標の定義
    • 数値で定義視聴
      • Get PRCの呼び出しの99%が100ミリ秒以下で完了すること
    • ぱふぉーまんすかーぶを意識するなら
      • 90% → 1 milli
      • 99 % → 10 milli
      • 99.9% → 100 milli
    • スループット重視、レイテンシ重視で目標かえるのはあり。
  • ターゲットの選択
    • 現在のパフォーマンスにもどついてターゲット選んではいけない
    • シンプルさを保つ
    • 絶対は避ける
    • SLOは最小限に留める
    • 最初から完璧でなくても良い
  • 計測値のコントロール
    • SLIを計測してSLOと比較してアクション検討するループを回しましょう
  • SLOによる期待の設定
    • ユーザーの期待値と合わせる
      • 安全マージンを確保する
        • 内部的なSLOをユーザーに対するSLOよりも高く設定しておく。マージン。
      • 過剰達成を避ける
        • 依存しすぎないように

4.4 アグリーメントの実際

  • SLAの設定は難しい。
  • ユーザーに見せる内容は控えめにする

5章 トイルの撲滅

5.1 トイルの定義

  • プロダクションサビースを動作させることに関係する作業で手作業で繰り返し行われ、自動化することが可能であ、戦術的で朝的な価値を持たず作業量がサービスの成長に比例する傾向
    • 手作業であること
    • 繰り返されること
    • 自動化できること
    • 戦術的であること
    • 長期的な価値を持たないこと
    • サービスの成長に対してOであること

5.2 トイルは少ない方が良い理由

  • Googleは50%以下にする
  • Googleのコラムがあるので随時参照

5.3 エンジニアリングであるための条件

  • エンジニアリングの典型的なSREの活動はおおよそ下記のようなもの
  • トイルが50%超えるなら何かを判断しないとだめだ

5.4 トイルは常に悪なのか?

  • 少ないトイルはリフレッシュにもなる。小さな達成感も得られるので良い。トイルが多すぎる場合は検討が必要。
    • キャリアの停滞
    • モラルの低下
    • 混乱の発生
    • 進歩速度の低下
    • 習慣づけ
    • 摩擦の発生
    • 信義違反

5.5 まとめ

6章 分散システムのモニタリング

6.1 定義

  • モニタリング
  • ホワイトボックスモニタリング
  • ブラックボックスモニタリング
  • ダッシュボード
  • アラート
  • 根本原因
  • ノードとマシン
  • プッシュ

6.2 モニタリングの必要性

  • 理由
    • 長期的なトレンドの分析
    • 時間や、実験グループ間での比較
    • アラート
    • ダッシュボードの構築
    • アドホックな振り返り分析の進行
  • システムが自分で修復できないのであれば人間が対応する必要がある

6.3 モニタリングにおける妥当な期待値の設定

  • どのSREチームにも通常は最低一人のモニタリング担当がいる
  • 複雑な依存改装の扱いはしない
  • S/N比を高くしておく

6.4 症状と原因

  • モニタリングシステムは2つの疑問に答える必要がある
    • 何が壊れたのか
    • なぜ壊れたのか

6.5 ブラックボックスとホワイトボックス

  • ブラックボックスモニタリング
    • 実際に起きている問題を表現する
  • ホワイトボックスモニタリング
    • システム内部を精査するのに向いている

6.6 4大シグナル

6.7 テイルレイテンシに関する懸念(あるいはインスツルメンテーションとパフォーマンス)

6.8 適切な計測の粒度の選択

  • 計測の粒度は適切に!
  • 無駄なデータは取らない
  • サーバー内でサンプリングをしておき、それらのサーバーから順次データを収集して集計を行うようにする。

6.9 可能な限りシンプルに、ただしやり過ぎないこと

  • さまざまなメトリクス、閾値、パーセンタイルによるアラート
  • 考えられる原因を検出して知らせるための追加コード
  • 考えられる原因のそれぞれに関連するダッシュボード

6.10 原則のとりまとめ

  • チェックリストっぽいのがあるからあとで見返したい

6.11 長期間にわたるモニタリング

6.12 まとめ

7章 Googleにおける自動化の進化

7.1 自動化の価値

  • 一貫性
  • プラットフォーム
    • 間違いを集約
  • 光速な修復
  • 素早いアクション
  • 時間の節約

7.2 Google SREにとっての価値

  • メリットとトレードオフ。本当に大規模の場合はメリットがかつ。
  • 自動化
  • プラットフォームベースのアプローチ

7.3 自動化のユースケース

  • メタソフトウェア
  • ステップ
    • 自動改善
    • 外部でメンテナンスされるシステム固有の自動化
    • 外部でメンテナンスされる汎用の自動化
    • 内部でメンテナンスされるシステム固有の自動化
    • システムが自動化を必要としていない

7.4 自分の仕事の自動化:何もかも自動化する

  • 読みましょう

7.5 苦痛の緩和:クラスタのターンアップへの自動化の適用

  • 読みましょう

7.6 Borg:ウェアハウススケールコンピュータの誕生

  • 読みましょう

7.7 基本的機能としての信頼性

  • 信頼性は基本の機能。自律的で弾性を持つ動作はその実現に役に立つ。

7.8 自動化のすすめ

  • 自動化のメリットは時間の節約だけではない。

8章 リリースエンジニアリング

  • ソフトウェアをビルドしてリリースすること
  • スキルセットには
    • 開発
    • 設定管理
    • テストの統合
    • システム管理
    • カスタマーサポート
  • 再現性もあり、自動化された方法で構築

8.1 リリースエンジニアの役割

8.2 哲学

  • セルフサービスモデル
    • 各開発チームがリリース頻度と時期を決められる
    • エンジニアの作業が最小限ですむところまで自動化可能
  • 高速性
    • リリースを頻繁にすることでバージョンの変更を少なくする
    • Push on Green
    • ビルド1時間ごとに実施 → そのなかからデプロイ
  • 密封ビルド
    • ビルドマシンに依存せず同じバイナリをビルドできる
  • ポリシーと手順の矯正
    • xxx

8.3 継続的ビルドとデプロイメント

  • ビルド

8.4 設定管理

  • 設定でのメインラインの使用
  • MPMパッケージへの設定ファイルとバイナリの同梱
  • MPMの設定パッケージへの設定ファイルのパッケージ化
  • 外部ソースからの設定ファイルの読み取り

8.5 まとめ

  • リリースエンジニアリングは初期からやっておくべし

9章 単純さ

  • システムはユーザーベースが変わらないのであればずっと同じ。
  • わたしたちのしごとはシステム兄でのアジリティと安定性のバランスをとること

9.1 システムの安定性とアジリティ

  • xxx

9.2 退屈の美徳

  • 予想がいのことが起きない状態が望ましい
  • SREは下記をやるべき
    • 受け持っているシステムに想定外の複雑さが生じていたら差し戻す
    • 関わっているシステムや運用を受け持つことになるシステムから複雑さを取り除く努力を継続的に行う

9.3 自分のコードはあきらめないぞ!

  • コードを精査してビジネス上のゴールへと動かしているか?
  • 定期的にデッドコードを削除
  • 肥大化したコードを検出する仕組み

9.4 削除した行の計測

  • ソフトウェアの肥大化を防ごう
  • 不要なコードは削除する。肥大化する追加は懐疑的になる

9.5 最小限の API

  • 最終的に完璧なものが生まれるのは追加するものがなくなったときではなく、削除するものがなくなったときである
  • 得テキの問題を回避するという判断を意識的に下すことにより、重要な問題に集中するとともに作成することに決めたソリューションを大きく改善できる

9.6 モジュラー性

  • オブジェクト指向プログラミングに適用っされる経験則の多くが分散システムの設計にも当てはまる
  • APIが提供するモジュール性は単純

9.7 リリースの単純さ

  • 単純なリリースは容易

9.8 単純な結論

  • xxx

第Ⅲ部 実践

Ⅲ.1 モニタリング

Ⅲ.2 インシデント対応

Ⅲ.3 ポストモーテムと根本原因分析

Ⅲ.4 テスト

Ⅲ.4.1 キャパシティプランニング

Ⅲ.5 開発

Ⅲ.6 プロダクト

Ⅲ.7 Google SREが推奨する参考文献

10章 時系列データからの実践的なアラート

  • 全体テキにBorgmon のはなし

10.1 Borgmonの誕生

  • 大量の収集を行うためにはメトリクスのフォーマットは標準化されていないといけない

10.2 アプリケーションのインスツルメンテーション

10.3 エクスポートされたデータの収集

10.4 時系列のアリーナにおけるストレージ

10.5 ルールの評価

10.6 アラート

10.7 モニタリングのトポロジーのシャーディング

10.8 ブラックボックスモニタリング

10.9 設定のメンテナンス

10.10 10年が経過して

  • アラートのルールの量とは関係なくモニタリングの対象と鳴るシステムのサイズをスケールできようになった。
  • そのために時系列データに対する集中化されたルールの評価に置き換えた

11章 オンコール対応

11.1 イントロダクション

  • 50%ルール

11.2 オンコールエンジニアの日常生活

  • SLOによって活動内容は変化する
  • ページイベントが優先
  • プライマリ、セカンダリ

11.3 バランスの取れたオンコール

  • 25%がオンコール
  • 運用の過負荷

11.4 安心感

  • 明確なエスカレパス
  • しっかりと規定されたインシデント管理の手順
  • 避難をともなわなわないポストモーテム文化

11.5 不適切な運用負荷の回避

11.6 まとめ

12章 効果的なトラブルシューティング

  • 学ぶことも教えることもできる

12.1 理論

  • プロセス
  • 積極的にシステムを手当してみる
  • 落とし穴
    • 関係ない症状を見てしまったり、システムのメトリクスの意味を取り違える。
    • 安全かつ効率的に仮設を検証するたj目のシステムやシステムへの入力を誤解
    • 生じている問題に対してありえないような仮設を思いついたりする
    • 偶然だったり共通の原因をもつようなことに対して間違った関連性を見出す

12.2 実践

  • 問題のレポート
    • 問題のrペオートから始まる
      • 期待と実際
    • 小さくても一つの問題ごとにチケットを起票
    • 多くのチームでは直接誰かに問題を報告することは推奨されていない
      • 手間もかかるし、他のメンバーから見えないレポートになる
  • トリアージ
    • システムがその環境下でできる限りうまく動作するようにする
    • 最優先するべきは出血をとめること
  • 検証
    • メトリクス
    • ロギング
    • 障害箇所の可視化
    • 純化と削減
      • テストデータを流し込む
      • 分割統治法
    • 何がどこでなぜ
    • 最後の修正
      • システムに対して直近に生じた変化は問題を特定する飢えで効率的な出発点になる
      • それをみるための可視化
  • テストと対応
    • 本誌を読もう

12.3 否定的な結果の素晴らしさ

  • 実験が期待通りに行かなかったときの話
  • これは過小評価するべきではない
  • 否定的な結果が出た実験は決定的なもの
    • それらのレポオートが他のチームに役立つかも
  • ツールや方法論は実験より長く残るもの
  • 否定的な結果を公開することはデータ駆動の文化を改善する
    • 否定的な結果や、統計的有意性の欠如を明確に説明することがメトリクスるにおけるばいあバイアスさげ、不確実性を慎重に受け入れる例を他社に示す。
  • 結果は公開しましょう
  • 対策
    • ポストモーテムかこうね

12.5 トラブルシューティングを容易にするために

12.6 まとめ

13章 緊急対応

13.1 システムが壊れた際に行うこと

  • 人に頼ろう

13.2 テストによって引き起こされた緊急事態

  • Googleでは予防的なアプローチを採用している
  • SREは障害を発生させて、改善を実施する。
    • コントロールされた障害は計画通りに進むもの
    • 想定外のことは起こりうる
  • 事象詳細
    • 100個あるデータベースの一個をロックする
  • レスポンス
    • ライブラリの依存関係を修正
  • 障害からわかったこと

13.3 変更が引き起こした緊急事態

  • 詳細
    • Googleの多くのサービスが依存するインフラストラクチャの変更がエラーループに陥った

13.4 プロセスが引き起こした緊急事態

13.5 解決できない問題は存在しない

13.6 過去から学び、繰り返さない

  • 書き記しておくことは大事。
  • 過去から学ぶ。
  • ありそうなことを記述しておく
  • 予防的なテストをしよう

13.7 まとめ

14章 インシデント管理

14.1 管理されていないインシデント

  • 各自が自分の考えで行動してサーバーダウン

14.2 管理されていないインシデントの詳細分析

  • 技術的な問題への極端な集中
  • 貧弱なコミュニケーション
  • 勝手な動き

14.3 インシデント管理のプロセスの構成要素

  • 責任の再帰的な分離
    • 領域を完全に分ける。同僚の動きを予想しなくて住むように
    • 高負荷になったらリーダー層にリソース調整を依頼する
    • 役割分担としては下記
      • インシデント指揮者
        • 高レベルの状況を把握
        • 移譲していないすべての役割を受け持つ
      • 実行作業
        • 実行作業チームがシステムを修正する
      • コミュニケーション
        • 外部とのコミュニケーション担当
        • ドキュメントを正確かつ最新に保つ
      • 計画
        • 長期的な課題を扱う
  • 明確な司令所
    • 関係者はどこで司令者とやりとりできるか
  • ライブインシデント状況ドキュメント
    • テンプレあるとよいね
    • Google docとか
  • はっきりした引き継ぎ
    • 明言する

14.4 管理されたインシデント

  • 本を読む

14.5 インシデントと宣言すべき場合

  • インシデント扱いするのは早いほうがいい
  • 条件を決めておく
      • その問題を修正するのに他のチームが必要化
      • ユーザー影響があるか
      • 集中して1時間分析をしてもその問題はまだ解決していないか

14.6 まとめ

  • ベストプラクティスが描いてある
    • 優先順位
      • 止血
      • サービス回復
      • 根本原因の証拠保存
    • 準備
    • 信頼
    • 自己観察
    • 代案の検討
    • 訓練
    • 持ち回り

15章 ポストモーテムの文化:失敗からの学び

15.1 Googleにおけるポストモーテムの哲学

  • 非難のないアクションのための改善のためのもの
  • 避難してはミスは出続ける
  • ポストモーテムを書く定義はしておいたほうがベター

15.2 コラボレーションと知識の共有

  • ポストモーテムは上級エンジニアにレビューしてもらうべし
    • 後のためにインシデントの主要なデータは収集されたか
    • インパクトの分析は完全か
    • 根本原因は十分に分析されているか
    • アクションプランは適切か?その結果として行われたバグの修正には適切な優先順位が与えられているか
    • 結果は関係するステークホルダーたちと共有された

15.3 ポストモーテムの文化の導入

  •  非難のないポストモーテムはエンジニアたちが自発的にやるべき
    • 今月のポストモーテム
    • Socialでやる
    • ポストモーテム読書会
    • 不運の輪

15.4 まとめと改善の継続

16章 サービス障害の追跡

16.1 Escalator

16.2 Outalator

17章 信頼性のためのテスト

17.1 ソフトウェアテストの種類

  • 伝統的なテスト
    • ユニット
    • 結合
    • システム
  • プロダクションテスト
    • 設定テスト
      • 設定ファイルがそのまま使われている場合は設定テストは単純
      • バイナリのデフォルト値や、bashの引数、共通ライブラリの挙動指定などをじっししている実施している場合は結構難しくなる
    • ストレステスト
    • カナリアテスト
      • バイナリを焼き上げる

17.2 テストの作成と環境の構築

  • 様々な質問
    • 本書を読もう
  • CI/CDなどがコケたら即座に治そうね

17.3 大規模なテスト

  • スケーラブルなツールのテスト

17.4 まとめ

18章 SREにおけるソフトウェアエンジニアリング

18.1 SRE内でのソフトウェアエンジニアリングの重要性

18.2 Auxonのケーススタディ:プロジェクトの背景と問題の領域

18.3 インテントベースのキャパシティプランニング

18.4 SREにおけるソフトウェアエンジニアリングの推進

18.5 まとめ

19章 フロントエンドにおけるロードバランシング

19.1 パワーは解答にあらず

19.2 DNSを使ったロードバランシング

19.3 仮想 IPアドレスでのロードバランシング

20章 データセンターでのロードバランシング

20.1 理想的なケース

20.2 不良タスクの特定:フロー制御とレイムダック

20.3 サブセットの設定によるコネクションプールの制限

20.4 ロードバランシングのポリシー

21章 過負荷への対応

21.1 「クエリ /秒」の落とし穴

21.2 顧客単位での制限

21.3 クライアント側でのスロットリング

21.4 重要度

21.5 利用率のシグナル

21.6 過負荷によるエラーへの対応

21.7 接続によって生じる負荷

21.8 まとめ

22章 カスケード障害への対応

  • カスケード障害とはドミノ倒しのようにまとまってドバっとくるやつ

22.1 カスケード障害の原因及び回避のための設計

  • 原因としては
    • サーバーの過負荷
    • リソースの枯渇
      • CPU
      • メモリ
      • スレッド
      • ファイルディスクリプタ
      • リソース間の依存関係
        • 1つの枯渇から他の枯渇へ
    • 利用できないサービス

22.2 サーバーの過負荷の回避

  • 対策としては…
    • 負荷試験
    • 品質を落とした結果の返却
    • 過負荷時のリクエスト拒否の仕組みを仕込む
    • より高レベルのシステムでリクエストを拒否するシステムを用意する
  • キューの管理
  • ロードシェディングとグレースフルグラデーション
    • ロードシェディング
  • リトライ
  • レイテンシとタイムアウト

22.3 起動直後の低パフォーマンスとコールドキャッシュ

  • 起動直後はやべぇ

22.4 カスケード障害を引き起こす条件

  • プロエスの停止
  • プロセスのアップデート
  • ロールアウト
  • 自然な利用の増大
  • 計画済みの変更、ドレイン、ターンダウン

22.5 カスケード障害に備えるためのテスト

  • テストによる障害の発生とその後の観察
  • 一般的なクライアントのテスト
  • 重要度の低いバックエンドのテスト

22.6 カスケード障害に対応するためにすぐに行うべき手順

  • リソースの追加
  • へるちぇの障害が引き起こさないようにする
  • サーバーの再起動
  • トラフィックのドロップ
  • でグレーデッドモードへの移行
  • バッチ不可の削除
  • 問題のあるトラフィックの排除

22.7 まとめ

23章 クリティカルな状態の管理 :信頼性のための分散合意

23.1 合意を利用する目的:分散システムの協調障害

  • スプリットドレイン問題
  • 人間の介入を必要とするフェイルオーバー
  • 問題のあるグループメンバーシップアルゴリズム

23.2 分散合意の動作

23.3 分散合意のためのシステムアーキテクチャパターン

  • 信頼性を持つ複製ステートマシン
  • 信頼性をもつ複製データストア及び設定ストア
  • リーダー選出を利用する高可用性を持つ処理
 

23.4 分散合意のパフォーマンス

23.5 分散合意ベースのシステムのデプロイ

23.6 分散合意システムのモニタリング

23.7 まとめ

24章 cronによる分散定期スケジューリング

24.1 cron

24.2 cronジョブと冪等性

24.3 大規模環境における cron

24.4 Googleにおける cronの構築

24.5 まとめ

25章 データ処理のパイプライン

25.1 パイプラインのデザインパターンの起源

25.2 シンプルなパイプラインパターンでのビッグデータの初期の効果

25.3 定期的なパイプラインパターンでの課題

25.4 不均衡な負荷の配分によるトラブル

25.5 分散環境における定期パイプラインの欠点

25.6 Google Workflowの紹介

25.7 Workflowにおける実行のステージ

25.8 ビジネスの継続性の保証

25.9 まとめ、そして終わりに

26章 データの完全性:What You Read Is What You Wrote

26.1 データの完全性への厳格な要求

26.2 データの完全性及び可用性の管理における Google SREの目標

26.3 データ完全性の課題への Google SREの対処

26.5 データの完全性に対する SREの一般原則の適用

26.6 まとめ

27章 大規模なプロダクトのローンチにおける信頼性

27.1 ローンチ調整エンジニアリング

27.2 ローンチプロセスのセットアップ

27.3 ローンチチェックリストの開発

27.4 信頼性のあるローンチのためのテクニック

27.5 LCEの発展

27.6 まとめ

第Ⅳ部 管理

Ⅳ.1 Google SREが推奨する参考文献

28章 SREの成長を加速する方法:新人からオンコール担当、   そしてその先へ

28.1 自分の後継 SRE(たち)を雇用した後にすべきことは?

28.2 初期の学習経験:混沌ではなく構造を提供する

28.3 優れたリバースエンジニアリングと柔軟な思考の育成

28.4 上を目指すオンコール担当者の 5つのプラクティス

28.5 オンコールの担当、そしてその先:通過儀礼と継続的な教育の実践

28.6 まとめ

29章 割り込みへの対処

29.1 運用負荷の管理

29.2 割り込みへの対処を決定する要素

29.3 不完全なマシン

30章 SREの投入による運用過負荷からのリカバリ

30.1 フェーズ 1:サービスの学習と状況の把握

30.2 フェーズ 2:状況の共有

30.3 フェーズ 3:変化の推進

30.4 まとめ

31章 SREにおけるコミュニケーションとコラボレーション

31.1 コミュニケーション:プロダクションミーティング

31.2 SRE内でのコラボレーション

31.3 SRE内でのコラボレーションのケーススタディ:Viceroy

31.4 SRE外でのコラボレーション

31.5 ケーススタディDFPにおける F1へのマイグレーション

31.6 まとめ

32章 進化する SREのエンゲージメントモデル

32.1 SREのエンゲージメント:その対象、方法、理由

32.2 PRRモデル

32.3 SREのエンゲージメントモデル

32.4 プロダクションレディネスレビュー:単純 PRRモデル

32.5 単純 PRRモデルの進化形:早期エンゲージメント

32.6 進化するサービス開発:フレームワークと SREプラットフォーム

32.7 まとめ

第V部 まとめ

33章 他の業界からの教訓

33.1 業界のベテランたち

33.2 準備とディザスタテスト

33.3 ポストモーテムの文化

33.4 反復業務と運用のオーバーヘッドの自動化

33.5 構造化された合理的判断

33.6 まとめ

34章 まとめ

ファシリテーター

 
  • 良さげなスキル
    • 相手の緊張を解すようなかんたんな質問から初めて次第に確信に迫る質問にシフトしていく☆
    • フェアであることは大切だ。発言を記録しているだけではなく、時には反対の立場に立って異なる視点から発言を促すことも必要
  • ファシリテートとは
  • インテグレーションワークショップ
    • センタ長が自己紹介と今年の目標と抱負を述べる
    • 退場
    • センタ長について知っていることを上げてもらう
    • 知りたいことを上げてもらう
    • 知っておいてほしいこともあげてもらう
    • 目標を達成するにはどうするのかをあげてもらう
    • 全員退出、センタ長入室
    • 議論の内容をファシリテーターがセンタ長に伝える
    • 全員入室
    • センタ長が質問やコメントに回答する
    • 飲み会
    • アクションプランについては持ち越し議論
  • GE式ワークアウト
    • ひたすらストレッチする
    • システムシンキングを育てる
    • 既成概念にととらわれない水平思考を促す
    • 本当の権限移乗と説明責任を生み出す
    • 短サイクルでの変革とすばやい意思決定を手にする
  • オンブズマン制度
    • 匿名で相談
  • ジョハリの窓
    • 懸念を言語化して表面化させるほうが近道。
      • 受容
      • データ流動
      • 目標形成
      • 社会的統制
  • ベストプラクティス
  • ストレッチゴール
  • 目標を合意することが最も大切、やり方はあとから付いてくる
  • SWOT
    • 掛け算の絵もあると良さそう
  • ディスカッションは範囲を絞ってやるとアイディアが出やすい
  • 目隠し
  • Wowをつくる
    • これできたらすごいよね!!があると良い
  • アイスブレーク
    • 感情的になった気持ちを解くために使ったりもする
  • 深く考える前に発言する
  • 使える質問
    • 全体を意識させる質問
      • システム全体でのどこの役割かを認識させる
    • 分散を意識させる質問
      • 平均値で議論しがち
    • 自分たちが制御できる・できないを意識させる質問
      • 制御できるところに目を向けさせる
    • 時間軸・基準を意識させる質問
  • 発言しにくい場合はファシリテーターが覗いてあげる
    • 匿名にするとか
    • グループを変えてみるとか
  • この よう な ファシリテーション・スキル について、 日本語 で まとめ られ た 好著 として、 堀 公 俊 著『 問題 解決 ファシリテーターファシリテーション 能力」 養成 講座』( 東洋経済新報社、 二 〇 〇 三年)、 同『 ファシリテーション 入門』( 日 経文 庫、 二 〇 〇 四 年)、 フラン・リース 著、 黒田 由 貴 子 + P・Y・インターナショナル 訳『 ファシリテーター 型 リーダー の 時代』( プレジデント 社、 二 〇 〇 二 年) が ある。 参考 にさ れ たい。
  • 森 時彦. ザ・ファシリテーター (Kindle の位置No.1557-1560). ダイヤモンド社. Kindle 版.
  • 早めにオフラインに切り替えるやり方を取る
  • モアオアレス
    • ある状態になったときに増えるもの、減るものをイメージして意識合わせを実施する手法
  • 全体最適
    • 会社としてはどうなの?組織最適ではなく、役割としてマッピングする
  • ゴールツリー
    • ゴールを分解、更に分解、アクションにする
  • ファシリテーターは色々ツールの使い分けが必要
  • 嘘つき自己紹介
  • ファシリテーター道具箱
  • 挑発的ファシリテーション
    • コンフォートゾーンからストレッチゾーンへ連れ出す

人を動かす

人を動かす

PART1 人を動かす三原則

盗人にも五分の理を認める

  • 大犯罪でも自分では正しいことをしていると思ってる
  • ワナメーカー「三十年前に、私は人を叱りつけるのは愚の骨頂だと悟った。自分のことさえ、自分で思うようにはならない。天が万人に平等な知能を与えたまわなかったことにまで腹を立てたりする余裕はとてもない」
  • 自分がどれだけ間違っていても認めたがらないもの
  • 偉大な心理学者ハンス・セリエ 「我々は他人からの賞賛を強く望んでいる。そして、それと同じ強さで他人からの非難を恐れる」
  • 人を非難することは無益
  • 悪い人間ほど自分のことは棚に上げて、人のことを言いたがる。それが人間の天性なのだ
  • なぜ自分の欠点を改めようとしないのだろう
  • およそ人を扱う場合には、相手を論理の動物だと思ってはならない。相手は感情の動物であり、しかも偏見に満ち、自尊心と虚栄心によって行動するということをよく心得ておかねばならない。
  • 若い時は人づきあいが下手で有名だったベンジャミン・フランクリンは、後年、非常に外交的な技術を身につけ、人を扱うのがうまくなり、ついに、駐仏アメリカ大使に任命された。彼の成功の秘訣は「人の悪口は決して言わず、長所をほめること」だと、自ら言っている。
  • 「偉人は、小人物の扱い方によって、その偉大さを示す」
  • 人を非難する代わりに、相手を理解するように努めようではないか。
  • 人を動かす原則 ❶|批判も非難もしない。苦情も言わない。

重要感をもたせる

  • 自ら動き出したくなるようこと
  • 人を動かすには相手の欲しがっているものを与えるのが唯一の方法
  • 2つの衝動
  • 性の衝動
  • 偉くなりたい衝動(重要人物たらん衝動)
  • 自己重要感
  • 自己の重要感を満足させる方法は、人それぞれに違っており、その方法を聞けば、その人物がどういう人間であるかがわかる
  • 「私には、人の熱意を呼び起こす能力がある。これが、私にとっては何物にも代えがたい宝だと思う。他人の長所を伸ばすには、ほめることと、励ますことが何よりの方法だ。上役から叱られることほど、向上心を害するものはない。私は決して人を非難しない。人を働かせるには激励が必要だと信じている。だから、人をほめることは大好きだが、けなすことは大嫌いだ。気に入ったことがあれば、心から賛成し、惜しみなく賛辞を与える」 
  • 名優アルフレッド・ラントも、「私に最も必要な栄養物は、自己評価を高めてくれる言葉だ」と言っている
  •  人間は、何か問題があってそれに心を奪われている時以外は、たいてい、自分のことばかり考えて暮らしている。そこで、しばらく自分のことを考えるのをやめ、他人の長所を考えてみることにしてはどうだろう。
  • 深い思いやりから出る感謝の言葉を振りまきながら日々を過ごす──これが、友をつくり、人を動かす秘訣である。
  • 「この道は一度しか通らない道。だから、役に立つこと、人のためになることは今すぐやろう──先へ延ばしたり忘れたりしないように。この道は二度と通らない道だから」
  • 人を動かす原則 ❷|率直で、誠実な評価を与える。

人の立場に身を置く

  • 好物を置く
  • 釣り針にはには魚の好物をつけるに限る
  • 人を動かす唯一の方法は、その人の好むものを問題にし、それを手に入れる方法を教えてやることだ。
  •  人を説得して何かやらせようと思えば、口を開く前に、まず自分に尋ねてみることだ──「どうすれば、そうしたくなる気持ちを相手に起こさせることができるか?」
  • 終始、相手の要求について語り、どうすればその要求が満たせるかを話したのである
  • 「成功に秘訣というものがあるとすれば、それは、他人の立場を理解し、自分の立場と同時に、他人の立場からも物事を見ることのできる能力である」
  • 「まず、相手の心の中に強い欲求を起こさせること。これをやれる人は、万人の支持を得ることに成功し、やれない人は、一人の支持者を得ることにも失敗する」
  • 人を動かす原則 ❸|強い欲求を起こさせる。

PART2 人に好かれる六原則

誠実な関心を寄せる

  • 相手の関心を引こうとするよりも、相手に純粋な関心を寄せるほうが、はるかに多くの知己が得られるということを、ティピーは不思議な本能から知っていたのである。
  • 「まずあなたが相手に関心を持たないとすれば、どうして、相手があなたに関心を持つ道理があろうか?
  • 他人のことに関心をもたないひとは、苦難の人生を歩まねばならず、他人に対しても大きな迷惑を掛ける。人間のあらゆる失敗はそういう人たちの間から生まれる。
  • 作者が人間を好きでないなら、世間の人もまたその人の作品を好まない
  • 世界一の奇術師は、舞台に立つときに「私はお客様を愛している」と思う
  • 友を作りたいなら、まず人のために尽くすことだ
  • 人に好かれる原則❶|誠実な関心を寄せる。

笑顔を忘れない

  • 「笑顔を見せる人は、見せない人よりも、経営、販売、教育などの面で効果を上げるように思う。笑顔の中には、渋面よりも豊富な情報が詰まっている。子供たちを励ますほうが、罰を与えるよりも教育の方法として優れているゆえんである」
  • 人に好かれる原則❷|笑顔で接する。

名前を覚える

  • 自分の名前を覚えていて、それを呼んでくれるということは、まことに気分のいいもので、つまらぬお世辞よりもよほど効果がある。逆に、相手の名を忘れたり、間違えて書いたりすると、厄介なことが起こる。
  • ビジネスには相手の名前をつけたりする
  • いくら忙しくても、フランクリン・ルーズヴェルトよりも忙しい人はいないはずだ。そのルーズヴェルトが、たまたま出会った一介の機械工の名を覚えるために、時間を割いている
  • 相手の名前がはっきり聞き取れない場合には、「済みませんが、もう一度言ってください」と頼む。もし、それがよほど変わった名前なら、「どう書きますか」と尋ねる
  • 人に好かれる原則❸|名前は、当人にとって、最も快い、最も大切な響きを持つ言葉であることを忘れない。

聞き手にまわる

  • 私の家には小さな屋内庭園があり、屋内庭園に関する疑問を二、三持っていたのだが、彼の話を聞いて、その疑問がすっかり解けた。
  • 人の話をよく聞くことは、ビジネスの世界だけでなく、家庭生活でも同じように大切だ。
  • じっと終わりまで耳を傾けてくれる人に対しては、たいてい大人しくなるものである。
  • 一、相手の話を、決して長くは聞かない。
  •  一、終始自分のことだけをしゃべる。
  • 一、相手が話している間に、何か意見があれば、すぐに相手の話をさえぎる。
  • 相手はこちらよりも頭の回転が遅い
  • 自分のことだけしか考えない人間は教養のない人間である
  • 人に好かれる原則④ 聞き手に回る

関心の在り処を見抜く

  • ルーズベルトは誰かが来るときには、その人が好きそうなことについて予めちゃんと調べていた
  • 相手の関心を見抜き、それを話題にするやり方は双方の利益になる
  • 相手次第で成果も違うが、誰と話をしてもそのたびに自分の人生が広がる
  • 人に好かれる原則⑤ 相手の関心を見抜いて話題にする

心からほめる

  • 彼のために尽くしてやり、彼に負担をかけない
  • 常に相手に重要感を持たせること
  • 自分を重要な存在だと考えていた。当然のことだ。人間はほとんど例外なくそう考えている
  • 人に好かれる原則⑥ 重要感を与える、誠意を込めて。

PART3 人を説得する十二原則

議論を避ける

  • 議論に負けても、その人の意見は変わらない
  • ただし期が上にも正しき議論をいくらしたところで、相手の心は変えられない。その点、正しからざる議論をするのと何ら違いはない。
  • 意見の不一致を歓迎せよ
  • 最初に頭をもたっげる自己防衛本能に押し流されてはいけない
    • 自分の立場を守ろうとする本能に負けるな
  • 腹を立ててはいけない
  • まず相手の言葉に耳を傾けよ
  • 意見が一致する点を探せ
  • 相手の意見をよく考えてみる約束をし、その約束を実行せよ
    • 相手の主張をよく考えてみる約束をするほうが良い
  • 相手が反論するのは関心があるからで、大いに感謝するべきだ
  • 早まった行動を避け、双方がじっくり考え直す時間をおけ
  • 人を説得する原則① 議論に勝つ唯一の方法として議論を避ける

誤りを指摘しない

  • 誤りを指摘することは、「私はあなたより頭がよい。よく言い聞かせて君の考えを変えてやろう」と頭ごなしにいっているようなものだ
  • やるなら相手に気付かれないようにやる
  • 我々が重視しているのは危機にひんした自尊心
  • 相手が誰であろうと口論してはいけない。相手の間違いを指摘して怒らせるようなことはせず、いささか外交的手法を用いよ
  • 人を説得する原則② 相手の意見に敬意を払い、誤りを指摘しない

誤りを認める

  • 自分が悪いと知ったら、相手にやっつけられる前に自分でじぶんをやっつけておいたほうが良い
  • 自分が正しいときには相手を優しく巧妙に説得しようじゃないか。また、自分が間違っているときはすみやじかに自分の誤りを快く認めるようにしよう。このほうがよほど愉快な気持ちになれる。
  • 人を説得する原則③ 自分の誤りを直ちに快く認める

穏やかに話す

  • 相手を自分の意見に賛成させたければまず諸君が彼の味方だとわからせることだ
  • 北風と太陽
  • バケツ一杯の苦渋よりも一滴のはちみつのほうが多くのハエを取れる
  • 人を説得する原則④ 穏やかに話す

エスと答えられる問題を選ぶ

  • 相手は一旦ノーと言ってしまうとそれを引っ込めさせるのは大変。自尊心の問題があるので。
  • 話し上手な人は相手にイエスと何度も言わせる
  • 相手の立場で物事を考えることは議論をするよりもかえって興味深く、比較にならぬほどの利益がある
  • ソクラテス式問答法
  • 人を説得する原則⑤ 相手が即座にイエスと答える問題を選ぶ

しゃべらせる

  • 相手に意義をはさみたくなっても我慢する必要がある
  • 人を説得する原則⑥ 相手にしゃべらせる

思いつかせる

  • 人から押し付けられたいけんよりも、自分で思いついたそれのほうが我々ははるかに大切にするものである
  • 川や海が数しれぬ渓流の注ぐところとなるのは、身を引く気に置くからである。そのゆえに、川や海はもろもろの渓流に君臨することができる。同様に、賢者は、人の上にたたんと欲すれば、ひとの下に身を置き、人の前に畳んと欲すれば、人の後ろに身を置く。かくして、賢者は人の上に立てども、人はその重みを感じること無く、人の前にたてども、人の心はキヅつくことがない
  • 人を説得する原則⑦ 相手に思いつかせる

人の身になる

  • 自らを顧みて、自分に対する強烈な関心と、自分以外の者に関する異いい加減な関心とを比較し、次に、その点については、人間は皆同じであることを考えれば、あらゆる職業に日宇町な原則を把握することができる。すなわち、人を扱う秘訣は、相手の立場に同情し、それをよく理解することだ
  • 自分の意見を述べるだけではなく、相手の意見をも尊重するところから、話し合いの道が拓ける。まず、話し合いの目的、方向をはっきりさせて、相手のみになって話をすすめ、相手の意見を受け入れていけば、こちらの意見も、相手は受け入れる
  • 人を説得する原則⑧ 人のみになる

同情を寄せる

  • あなたがそう思うのはもっともです。もし私があなただったら、やはり、そう思うでしょう
  • もし神様のお恵みがなかったら、この相手が、私自身の姿なのだ
  • 相手をやっつけるよりも相手に好かれる方がよっぽど愉快
  • 不幸な自分に対して自己憐憫を感じたい気持ちは程度の差こそあれ誰にでもある
  • 人を説得する原則⑨ 相手の考えや希望に対して同情を寄せる

美しい心情に呼びかける

  • 相手の信用状態が不明なときは彼を立派な紳士とみなし、そのつもりで取引をすすめると間違いがない
  • 人を説得する原則⑩ 人の美しい心情に呼びかける

演出を考える

  • 人を説得する原則⑪ 演出を考える

対抗意識を刺激する

  • 仕事には競争心が大切である。あくどい金儲けの競争ではなく、他人よりも優れたいという競争心を利用すべきである
  • ゲームの精神を取り入れることが重要
  • 成功者はみなゲームが好きだ。自己表現の機会が与えられる体。存分に腕をふるって相手に打ち勝つ機会、これが、いろりおな競争や競技を成立させる。優位を締めたい欲求、重要感を得たい願望を刺激するのだ
  • 人を説得する原則⑫ 対抗意識を刺激する

人を変える九原則

まずほめる

  • 褒める → 主張の流れ
  • 人を変える原則① まず褒める

遠回しに注意を与える

  • 褒める → しかしはよくない。そしてとつなげて相手を上げる。注意する。
  • 人を変える原則② 遠回しに注意を与える

自分の過ちを話す

  • 失敗も多いがと前置きして、それから間違いを注意すると相手は不愉快な思いをせずにすむ
  • 人を変える原則③ まず人の誤りを話したあと相手に注意する

命令をしない

  • 人を変える原則④ 命令をせず、意見を求める

顔を潰さない

  • 相手の顔を立てることは重要
  • 解雇の際にはめちゃくちゃ頑張ってくれたことをお伝えする
  • サンテグジュペリ「相手の自己評価を傷つけ、自己嫌悪に陥らせるようなことを言ったり、したりする権利は私にはない。大切なことは、相手が私がどう評価するかではなくて、相手が自分自身をどう評価するかである。相手の人間としての尊厳を傷つけることは犯罪なのだ」
  • 人を変える原則 ⑤顔をたてる

わずかなことでも褒める

  • 人を変える原則⑥ わずかなことでも惜しみなく心からほめる

期待をかける

  • 人を変える原則⑦ 期待をかける

激励する

  • 罵倒するよりも激励したほうが良い効果がある。
  • 自分の優秀さを示そうとがんばる
  • 人を変える原則⑧ 激励して、能力に自信を持たせる

喜んで協力させる

  • 下記をトライするべき
    • 誠実であれ、守れない約束はするな。自分の利益は忘れ、相手の利益だけを考えよ
    • 相手に期待する協力はなにか、明確に把握せよ
    • 相手の身になれ。相手の心の望みはなにか?
    • あなたに協力すれば相手はどんな利益があるか?
    • 望み通りの利益を相手に与えよ
    • 人にものを頼む場合、その頼みが相手の利益になると気づくように話せ
  • 人間は肩書が好き。それをあたえてもいいかも。
  • 人を変える原則⑨ 喜んで協力させる

GCP

 

第1章 Google Cloud Platform の特徴

  • GCPはPaaSからIaaSにすすんだプラットフォーム
  • Google自身がGCPの大きなユーザーの一人
  • ライフマイグレーション
  • 仮想マシンから物理サーバーへ移動させる技術
  • 可溶性が高い
  • グローバルネットワーク
  • クラウドを利用するには提供社の歴史などを考えてみることが大事
  • k8sはBorgというやつ
  • 自身がやりたいことに対しtえあっているのか?ということを検討する必要がある。GCPは「大規模分散コンピューティング」「インフラの隠蔽、共用化」といったことをやっている分野。メリットを理解する必要があります。

第2章 コンピューティングサービス

  • GCPのコンピューティングサービスは下記の4つ
  • GCE
    • 永続ディスクサイズは64TBが最大
    • 標準、ハイメモリー、ハイCPU、共有コアの四種類
    • 共有コア:リソースが小さくて大丈夫なもの。0.2, 0.5コアとか。こいつについては、3TBまでの永続化領域
    • ハイCPU: 96コアまで
    • ハイメモリー: 624Gバイトまで
    • GPUも独自に積んでいる。
      • ライブマイグレーション機能は使えない(仮想環境を利用しながら物理環境にマイグレする機能)
    • OS
    • ディスク
    • 課金
      • 確約利用割引
        • 利用期間をコミット
        • やすい
      • 継続利用割引
        • 利用課金
        • たくさん使えば単価が下がる
    • プリエンプティブルVM
      • やすいやつ
      • 起動後24時間以内に必ず停止される
      • システム需要に応じて必ず停止される
    • Compute Engineの基本機能
      • アクセス制御
        • IAM
        • インスタンス、ストレージ、ネットワークに対するアクセス制御
        • サービスアカウントを設けることで仮想マシンごとにGCPサービスを制御できる
      • 暗号化
        • 自動でやる
        • ユーザーが管理する鍵での暗号化も可能
      • バックアップ
        • スナップショット、イメージ作成
      • 拡張性
      • 対象外生
  • App Engine
    • PaaS
    • StandardとFlexible
      • SE
        • 機能制限が多い
        • 高いサービスレベルを維持したまま
      • FE
        • インスタンスの起動に分単位で時間がかかる
        • バックエンドのインスタンスにCompute Engineを利用しているのでローカルディスクへの書き込みが可能
        • そのため、GCEの利用料に応じた課金が発生する
        • GCEに発生しうる制約
    • Blue-Greenデプロイメント
      • ことなるばージョンのアプリケーションをデプロイする機能がある
      • バージョン指定のURL指定が可能。デプロイ後に確認してから切り替えが可能。
    • Cronサービス
      • キューイングのCronもできる
      • タスクを動かせる
    • セキュリティスキャン
    • App Engineの基本機能
      • アクセス制御
        • IAMを利用したアクセス制御
        • 全体管理?細かいところまで
        • ファイアーウォール系のもの
      • 暗号化
        • SE版はCloud datastoreやCloud Storageが利用される。これらは勝手に暗号化される。
        • FEの場合はGCEを利用するため、データ書き込み時に暗号化される
    • バックアップ
      • App Engineのバックアップ機能はない
      • データを保管する際は外部のデータストアを利用することが一般的(そうなん?)なので不要
  • Kubernetes Engine
    • 設定項目
      • ロケーション
        • どこに配置するか
        • 単一か分散化をせんたく
      • クラスタバージョン
        • マスターのノードに利用するバージョンを指定
      • マシンタイプ
      • ノードイメージ
        • OS
      • サイズ
        • ノード数
      • 自動スケーリング
        • オンにすることで
      • プリエンプティぷぶーど
        • 安いやつ使うかどうか
      • ろーかるSSD
        • 全ノードで利用するディスク数
      • ネットワークサブネット
      • コンテナアドレス範囲
    • Google Container Registry
    • 基本機能
      • アクセス制御
        • IAMとか
      • 暗号化
        • GCEと同様
      • バックアップ
        • 自動
      • 拡張性
        • 各コンテナに必要なCPUとかメモリ利用料を指定できる
      • 耐障害性
        • 自動修復機能
    • Cloud Functions
      • β版
      • 公式ドキュメントを後で読もう
      • コード実行単位での課金(100ミリ秒単位)

第3章 ストレージサービス

  • 下記の五種類存在する
    • google Cloud Storage
      • BLOB
      • オブジェクトストレージ
      • 画像とか
      • 非構造データ
      • S3相当機能
    • Google Cloud bigtable
      • ワイド型ストレージ
      • NoSQL
      • 性能重視
    • Google Cloud Datastore
    • Google Cloud SQL
      • リレーショナル・データベース
      • MySQLやPostgresSQLなどのマネージドサービス
    • Google Cloud Spanner
      • MySQLとか
      • グローバルで水平スケーリング機能を備えたリレーショナル・データベース
      • 高いトランザクション
    • Google Cloud Bigquery
      • 解析用
  • ストレージサービスの使い分け
    • 構造化データでない
      • Cloud Storage一択となる
      • 耐久性99.9999999(イレブンナイン)
    • 構造化データ
      • データ解析用でない
        • リレーショナルデータベース
          • 高調整?
            • Cloud Spanner
            • 水平スケーリング機能 Cloud SQL には備わっていない
            • 制約事項がある
          • その他
        • NoSQL
          • Cloud Datastore
          • Datastoreはサービス規模が拡大しても自動的にスケールする
          • 安価
      • データ解析用
        • 大容量のデータ保存が必要な場合
          • 低レイテンシを必要とする
            • Bigtable
            • はやい
            • 10 msec 以下で応答可能
          • 低レイテンシを必要としない
            • BigQuery
            • 準リアルタイム解析の場合はこちらを採用するのがベター
            • 比較的複雑なクエリを採用できる
  • Cloud Storage
    • S3相当のサービス
    • オブジェクトストレージ
    • 独自のCDNを持っている
    • エッジという拠点にデータが複製されるので、世界中からアクセスが可能
    • バケットとオブジェクト
      • バケット:データを格納する器
        • 格納オブジェクト数の上限はない
      • オブジェクト:データそのもの
        • 最大は 5TB
      • コンソール画面、コマンドライン、クライアントライブラリ、REST API経由
    • ストレージクラス
      • オブジェクト似合いしてストレージクラスが設定される
      • 可用性、耐久性、最小保存期間、料金が異なる
        • Multi-Regional
          • 地理的な冗長性を確保
          • 可用性: 99.95
          • 耐久性: 99.999999999 (nine-nine)
          • $0.026 GB/月
          • 世界中から頻繁にアクセスされるサービス
        • Regional
          • 単一リージョンで稼働
          • 可用性: 99.9
          • 耐久性: 99.999999999 (nine-nine)
          • $0.023 GB/月
          • Compute Engineから頻繁にアクセスされるデータ
        • Nealine
          • 月一回程度のアクセス
          • 可用性: 99.0
          • 耐久性: 99.999999999 (nine-nine)
          • $0.016 GB/月
        • Coldline
          • 年一回程度のアクセス
          • 可用性: 99.0
          • 耐久性: 99.999999999 (nine-nine)
          • $0.01 GB/月
      • Multi-RegionalクラスとRegionalは変更不可
      • デフォルトストレージクラスは随時変更可能
      • 次から格納されるデータがそこのクラスで適用される
      • ライフサイクル管理機能で、格納後の時間に応じて自動で別のクラスに移動できる。
    • アクセス制御
      • IAM
        • 基本はこっち
      • アクセス制御リスト(ACL
        • 細かく制御したい場合はこっち
        • 個々のリソースを制御したい場合はこちらを利用しよう
    • 暗号化
      • ディスクに格納される際に自動的に暗号化される
      • ユーザー指定の暗号鍵を用いて暗号化可能
        • この場合は一部サービスが利用d境内制約
        • 鍵の管理が大変。鍵を新しくする場合過去のデータは古い暗号鍵で暗号化されたまま
        • Cloud KMS (Key management system) がリリースされたがまだ利用できないかも?
    • バックアップ
      • バージョニング機能
        • オブジェクトを上書きするたびに古いものはアーカイブバージョンとして管理する
        • これはデフォルトでは機能
        • アーカイブバージョンも課金対象
        • ライフサイクル管理機能により、古いものは自動削除などの対応が可能
  • Bigtable
    • Apache HBase APIを用いてアクセス可能
    • フルマネージドNoSQLサービス
    • Googleのコアサービスはこれを利用しているらしい
    • 大規模、低レイテンシ、高スループット
    • 生い立ち
      • 10年以上利用されている基盤システム
      • Hadoopのもととなる技術を利用している
      • Apache Hbase Bigtableをべーすに実装された分散データベース
    • ストレージタイプ
      • SSD, HDD を選択可能
      • 切り替え困難
      • パフォーマンスが良いのでSSDを選ぶことをおすすめ
    • 基本機能
      • アクセス制御
        • IAMでの制御
      • 暗号化
        • 自動
        • ユーザー指定鍵は利用できない
      • バックアップ
        • テーブルにデータを書き込むと3台以上のサーバーに自動でレプリケートされる
        • 耐久性は高い
        • 論理バックアップが七曜な場合はユーティリティを利用したバックアップを検討したい
  • Datastore
    • アプリのバックエンドを想定して開発されたNoSQLデータベース
    • サービス規模が拡大しても自動でスケールされて、処理速度が変化しないこと
    • シャーディングとレプリケーションを自動でやる
    • 管理負荷が低い
    • オブジェクト指向データベース
      • RDBと同じ機能を備えているが、オブジェクト指向データベース日会
      • Java/Pythonなどのオブジェクトを永続化可能
      • Datastore
        • カテゴリ:カインド
        • オブジェクト単体:エンティティ
        • 個々のデータ:プロパティ
        • 一意Id:キー
    • コンシステンシー
      • 二種類の整合性レベルを選択できる
        • Strong consistency (強整合性)
          • 更新直後から結果が最新であることが保証される
          • 更新完了まで時間がかかる
        • Eventual Consistency
          • 更新後最新でない結果がが返却されることがある
          • 処理は高速
      • ユースケースにあわせて設計しようね
    • スキーマ設計
      • 利用できるクエリータイプはRDBMSで許可されているものより制限が厳しい
        • 結合オペレーション(JOIN)は利用できない
        • 複数の不等号j封建をもった検索処理がサポートされていない
        • サブクエリーの結果に基づいたデータに対する検索処理がサポートされていない
      • 非正規化を意識する設計が必要
    • 基本機能
      • アクセス制御
        • IAMを利用したアクセス制御
      • 暗号化
        • Datastore上のすべてのデータは自動的に暗号化
        • 鍵はGoogle側で管理されている
      • バックアップ
        • Datastoreに保存されたエンティティに対してCloud Storageにエクスポートする機能が備わっている
        • 書き込みを抑制する機能が備わっているので、そのバックアップデータの整合性を確保できる
  • Cloud SQL
    • Amazon RDsのようなサービス
    • MySQL、Postgresが選択可能
    • Oracle とかは利用不可
    • ジェネレーション
    • Cloud SQLの基本機能
      • 拡張性・耐障害性
        • FailOver replica機能が備わっている
        • マスターインスタンス障害児に自動でフェイルオーバーさせることが可能
        • ストレージの自動拡張機能がそなわっているRDBMSの設計監理から開放される点は利点
        • マスターが存在するゾーンが停止した場合のみfailoverする。ゾーン停止以外の理由でマスターが停止した場合はそれは発動しない
      • アクセス制御
        • IPアドレスでのアクセスポイント
        • ちゃんと制御しないと行けない
        • Cloud SQL Proxyを利用するとかできる
        • IAM
        • DBMSを利用制御も可能
      • 暗号化
        • データ転送中、保存時もすべて暗号化
        • 鍵はクラウド
      • バックアップ
        • 自動バックアップとオンデマンドバックアップが可能
        • 自動は4時間のバックアップ時間枠を指定することにより、その時間枠内で自動バックアップされるh
        • インスタンスで最大7世代がGoogle側で管理される
  • Spanner
    • 高い整合性と大規模水平スケーリングを備えている
    • RDB
    • クラウド前提のRDB設計
      • すきーま:構造化
      • SQL OK
      • 強整合性
      • Active-Active
      • Horizontal Scaling
    • 既存のRDBからのマイグレーションは難しい
    • マルチリージョンサポート
      • 特定のリージョンにルーティングされる
    • 設計上の制約
      • 従来型のCloud SQLは不要?
        • 物理レイアウトを意識した設計
          • ホットスポット(特定のテーブルんい処理が集中すること)を回避しないと期待したパフォーマンスを得られない、
          • インターリーブを利用してデータを分散配置させないようにクラスタ化が必要
        • データ操作や書き込みにSQLは利用できない
          • 読み取りやデータ定義にはSQLをサポートしているが
          • 操作や書き込みにひは利用できない
          • これはGoogleAPI経由でやる必要がある
        • 自動採番機能がない
          • RDBにはあるシーケンス番号をするような機能がないので、あぷりけーしょんがわで実装が必要
    • 基本機能
      • アクセス制御
        • IAM
      • 暗号化
        • 自動
        • ユーザー鍵NG
      • バックアップ
        • 論理バックアップ機能はある
        • 日時バックアップは取得しているため、GCPサポートに依頼することで日時バックアップからのリカバリは可能

第4章 ネットワーキングサービス

  • ネットワーキングサービスの種類
    • 下記の5種類ある
      • Virtual Private Cloud (VPC)
        • GCPリソースのために論理的に分離された仮想ネットワーク
      • Cloud Load Balancing
      • Cloud CDN
        • エッジポイントを提供するサービス
      • Cloud DNS
      • Cloud Interconnect
        • 自社オンプレミス環境からセキュアにネットワーク接続するサービス
  • VPC
    • ユーザー自身が定義したVPCネットワーク内でコンピューティングリソースを起動できる
    • VPC内のリソース同士をプライベートネットワークでつなげることができる
    • プロジェクト内にVPCを作成
    • 異なるリージョンに配置されたインスタンスでも同じVPCに所属できる。そのインスタンスGoogleのプライベートネットワークでアクセスする。
    • 異なるVPC内はインターネット経由で通信する
    • VPCネットワークとサブネットワーク
      • 複数のサブネットを定義可能
      • 1サブネットは1リージョン所属
      • デフォルトは
        • すべてのリージョンに1つのサブネットが作成された状態
      • 各サブネットにはRFC1918に従うプライベートIPアドレスがありり、GCPリソースを利用可能
      • リージョンとCIDRを指定するだけで、ゾーンにまたがったサブネットを作成可能
        • これはGCPの特徴
      • マルチゾーン構成がしやすい
    • 外部IPアドレス
      • GCPプロジェクトごとにIPは確保する
      • GCPではエフェメラルな外部IPアドレスを固定された外部IPに変換する機能がある
      • 固定IPにプロモートするようにしないといけない
      • 下記の2種類存在
    • ネットワーク通信制
      • ステートフルなファイアウォール
      • VPCごとにインバウンド、アウトバウンドを設定する
      • インバウンドは
        • ping, rdp, sshが許可
        • VPC内のすべての通信
        • ユーザー指定VPCではインバウンドはすべて遮断
      • アウトバウンドは、
        • すべて可
      • タグを設定することが可能。
      • タグはインスタンスに付与するラベル。IPを指定せずともタグのみでネットワーク通信制御を行うことができる
    • VPCネットワークピアリング
      • GCPでは異なるVPC感はインターネット経由
      • VPCネットワークピアリング機能を利用するとプライベート接続が可能になる
      • IPの重複がなければピリング設定だけで接続可能
      • VPCネットワーク間ではピアリングされていれば内部負荷分散機能を利用可能
      • VPCピアリングは最大25個まで直接ピアリングされたネットワークを設定することが可能
      • 異なるプロジェクト間でも利用可能
      • 自社オンプレ → vpn 東京リージョン → ピアリングした外部リージョン
    • 限定公開のGoogleアクセス
      • 外部IPがないCompute Engineはインターネット経由でGoogle APIGoogleのサービスにアクセスできない
      • Private Google Accessを利用すれば可能
        • この機能を利用すればVPC内部から下記のエンドポイントにアクセス可能
          • BigQuery
          • Cloud Bigtable
          • Cloud Dataproc
          • Cloud Datastore
          • Cloud Pub/Sub
          • Cloud Spanner
          • Cloud Storage
    • VPCネットワークにおける注意点
      • デフォルトVPCネットワーク
        • Ping, RDP, SSH を行うためのファイアーウォールルールが設けられている
        • そのままつかうなよ
      • 禁止された送信ポート
        • 25 465, 587は送信接続できない
        • SMTPポート
        • サードパーティプロバイダを利用しましょう
          • SendGrid
          • Mailgun
          • Mailjet
  • Cloud Load Balancing
    • ELBのようなアクセス増大する際には事前の申請が不要
    • HTTP負荷分散
      • HTTPリクエストを世界中のサーバーへ負荷分散する機能
      • 1グローバルIPで複数リージョンへの振り分けが可能
      • 外部クライアントからのリクエストは最もの遠いPoP (Point of Presence) で終端され、クライアントのアクセス元に最も近いリージョンに配置されたバックエンドインスタンスに転送される
      • Google Cloud CDNと連携して、世界中にあるGoogleのPoPを利用してクライアント近くにコンテンツをキャッシュして短い処理を実現する
      • 耐障害性も高い
      • コンテンツベースでの負荷分散も可能
      • Stackdeiver Logging のログビューアーからリクエスト状況を確認することが可能
    • ネットワーク負荷分散
      • TCP/SSL UDPプロトコルを利用するレイヤー
      • TCP/SSLに関しては複数リージョンにまたがった負荷分散が可能
      • TCP/UDP負荷分散は単一リージョンでの負荷分散
  • Cloud CDN
    • 世界中に分散しているGoogleのエッジポイントを利用してクライアントの近くにコンテンツをキャッシュする
    • コンテンツ更新時にCDNのキャッシュを削除したい場合は数分で削除可能
  • Cloud DNS
    • レイテンシー、高可用性のサービス
    • Cloud DNSでサポートされるレコードタイプ
      • A
        • アドレスレコード。ホスト名をIPv4にマップする
      • AAAA
        • IPv6アドレスレコード
      • CAA
      • CNAME
      • IPSECKEY
      • MX
        • メールエクスチェンジレコード
      • NAPTR
        • Naming Authority Pointer
      • NS
        • ネームサーバーレコード
      • PTR
        • ポインタレコード
      • SOA
        • Start of authority
        • DNSゾーンに関する信頼できる情報
      • SPF
        • Deplicated
      • SRV
      • SSHFP
      • TLSA
      • TXT
  • Cloud Interconnect
    • 自社オンプレ環境からGCP内のインスタンスに直接アクセスするサービス
    • 下記2種類のオプションがそんざいする
      • Dedicated Interconnect
        • 専用線で直接的な物理接続を行うサービス
        • 帯域は10Gビット/秒
        • ハイブリッドクラウド環境を構築する場合、高帯域のトラフィックを必要とする場合に有効な手段
        • SLA99.99%
  • IPsec VPN

第5章 ビックデータサービス

  • GCP
    • Cloud Pub/Sub
      • メッセージングサービス
    • BigQuery
      • データレイク
    • Cloud DataFlow
      • バッチ/オンラインのデータパイプライン
    • Cloud Dataproc
    • Cloud Datalab
      • データ分析、可視化、機械学習のための分析ツール
データ収集
データ蓄積
データ処理・分析
データ探索・可視化
Cloud Pub/Sub
 
 
 
 
Big Query
 
 
 
Cloud Dataproc
 
 
 
 
Cloud Dataflow
 
 
 
 
Cloud Datalab
  • BigQueryとDataprocの違い
    • 両方ともデータ蓄積、処理、分析ができるが性質やコンセプトが異なる
    • お互いを補完するサービスなので、特徴を踏まえて組み合わせて使っていくこと
  • Cloud Pub/Sub
    • メッセージングサービス
    • 低レイテンシ
    • 基本概念
      • googleapis.comにHTTPSリクエストを投げることでPub/Subにわたすことができる
      • 受信方法は2種類
        • Pull型
          • エンドポイントにHTTPSリクエストを投げることで受信
        • Push型
          • Pub/SubからのHTTPS POSTのリクエストを受け入れることで受信
    • メッセージライフサイクルと内部処理
    • システム設計をする上での考慮事項
      • Pub/Subはメッセージの順序制御を保証していない。そのため、そこは依存しないようなシステム設計にする必要がある
      • 順序制御が必要な場合あdatastoreやCLoud SQLを利用すればできなくはないが大変。非推奨。
    • at-least-once配信
      • 内部ストレージに保存したメッセージを順番に1回配信する。アプリケーションレベルで受信確認が行われるので、複数回配信もありえる。PussubI/Oを利用すれば、カスタムメッセージID、Cloud Pub/Subが割り当てたIDのメッセージの重複を排除することができる
  • 基本機能
    • アクセス制御
      • IAM
      • バックアップ
        • バックアップ、リストアの機能なし
        • 複数ドメインでデータ複製をしているので特に気にする必要なし
      • 暗号化
        • 通信はHTTPS暗号化
        • ストレージに保存される内容も暗号化済み
      • ネットワークセキュリティ
        • エンドポイントはインターネット越し
      • スケーリング
        • 負荷に応じてかってにスケーリング
      • 可用性
  • 主な利用方法
    • ストリーミングデータの受口として配置、バックエンドに配置したData flowなどに非同期で流す
    • コンポーネント疎結合にする
  • BigQuery
    • フルマネージドデータウェアハウスサービス
      • データウェアハウスとは、、、
      • データの保管から管理分析までを行うサービス
    • BigQueryは
      • ストリーミングデータ収集
      • データ保存のストレージサービス
      • クエリーエンジン
    • Dremelの技術を採用
    • 基本概念
      • 内部リソース
        • ストレージリソース
        • クエリリソース
          • CPUとRAMの演算能力
      • BigQueryを利用する際に意識するリソースは
        • テーブル
        • データセット
          • ここのテーブルを論理的に集約できる単位
          • ロケーションやアクセス制御はこの単位で実施
        • ビュー
          • クエリによって定義される仮想的なテーブル
        • ジョブ
          • 利用者が作成したアクション
    • システム設計する上での考慮事項
      • クエリーの種類
        • インタラクティブクエリー
          • 即時実行
          • 50個の同時実行レート
        • バッチクエリー
          • キューイングされてクエリリソースがアクティブになったタイミングで実行
          • 24時間以内に実行されない場合はインタラクティブクエリーになる
          • 数分以内に通常は実行される
          • 同時実行の制限なし
            • 大量実行はこっちの種類を選択
      • データインポートと更新
        • データ挿入処理に特化している
        • レコード単位でのデータ操作はできない
        • データソースから既存テーブルにインポートする場合は、データ追加か上書きしかできない
      • データセットとテーブルの単位
        • データセットは利用目的の単位で分割したほうが良い
      • BigQueryへの接続方法
      • クエリーの実行結果
        • 実行結果は一時テーブルに24時間自動的に保存される
        • 全く同じクエリーを実行した場合には一時テーブル及び永続テーブルの内容を返すのでクエリー課金は発生しない
        • クエリーの実行結果はCSVJSONでダウンロード可能
      • 料金
        • 定額料金
        • オンデマンド料金
    • 基本機能
      • アクセス制御
        • IAMを利用したプロジェクトレベルでのアクセス制御
        • データセットレベルでのアクセス制御
      • バックアップ
        • スナップショットが取得可能
        • 標準AQLのスナップショット機能はない
      • 暗号化
        • 保存時に暗号化
        • Cloud KMSも利用可能
      • ネットワークセキュリティ
        • DatastoreやCloud Storageからデータインポートする際にはGCPのプライベートネットワークを利用した通信が実施
        • BigQueryAPIを叩く場合にはインターネット経由でのアクセスになる\\
      • 可用性・耐障害性
      • モニタリング
        • クエリープラン
    • 主な利用方法
  • Cloud Dataflow
    • データ処理パイプラインサービス