2020-02-18

インフラエンジニアの必須知識を広く体系的に学べる「インフラエンジニアの教科書２」を読んだ

本読んだ

インフラの知識が割と必要な仕事だけど、「あれってなんだっけ？」と調べることが多く、「ちゃんと勉強しないとな〜」と思っていたときにお勧めいただいたのが「インフラエンジニアの教科書２」でした。（ちなみに「インフラエンジニアの教科書１」は読んでないのですが、全然問題なかったです。今後１の方も読んでみよう。）
プロトコルやOSから、セキュリティ攻撃、RFCの読み方など、本当に幅広い必須知識が紹介されています。（目次参照）
今まで曖昧に / 所々で理解していたことを体系的に学べました。また、いくつかのChapterでは、「インフラエンジニアは何を意識すべきか」という内容も盛り込まれていてすごく良かったです。
全体的に図解も多く、かなりサクサクと読めました。

インフラエンジニアの教科書2 スキルアップに効く技術と知識

作者:佐野裕
出版社/メーカー: シーアンドアール研究所
発売日: 2016/08/26
メディア: 単行本（ソフトカバー）

📖 目次

CHAPTER-01 プロトコル
CHAPTER-02 OS
CHAPTER-03 ネットワーク
CHAPTER-04 データベース
CHAPTER-05 WEBのサーバサイド開発言語
CHAPTER-06 共通鍵暗号方式と公開鍵暗号方式
CHAPTER-07 障害対策と障害対応
CHAPTER-08 よく知られたセキュリティ攻撃
CHAPTER-09 インターネットの運用と発展をつかさどる組織や団体
CHAPTER-10 RFCの読み方と作られ方
CHAPTER-11 世界規模のインターネットサービス運営
CHAPTER-12 インフラエンジニアとして目指す方向

「インフラエンジニアの〇〇」

Chapter2〜4の『インフラエンジニアの〇〇』では「Chapterのコンテンツに対してインフラエンジニアがどう関与するか」という内容が書かれており学びが多かったですし、本書籍の特徴的な部分だと感じました。

Chapter2-6 インフラエンジニアのプロセス管理
Chapter2-9 インプラエンジニアのメモリ管理
Chapter2-13 インフラエンジニアのファイル管理
Chapter3-16 インフラエンジニアのネットワーク管理
Chapter4-20 インフラエンジニアとデータベース

例えば、「Chapter3-16 インフラエンジニアのネットワーク管理」から抜粋すると、

「主に監視するのはdiscatd(packet loss)とunbind」

ネットワーク機器で監視できる項目は多々ありますが、[ 1 ] 特にdiscard値とunbindの発生は特に注視すべき監視項目です。
パケットロスなどにより発生するdiscard(packet loss)値は常に0であるべきですが、ちょっとしたdiscardはたまに発生します。discardが発生した場合、原因を徹底的に分析するのが好ましいです。discardが発生しうる要因として、[ 2 ]接続先機器側の問題、ケーブル不良、スイッチバッファが溢れたなどがあります。特に外部からのリクエストが多い環境においてはネットワーク機器のCPU使用率が高い場合やキャッシュを使い果たすほどの瞬間的に大量のパケットが流れ込んだ時にパケットロスが発生しやすくなります。このような場合は、[ 3 ]ネットワーク構成を変更してトラフィック流入を物理的に減らす方法や、より高性能のスイッチに買い替えるといった方法があります。

のように「[ 1 ]何に注意すべきか」「[ 2 ]どんな原因があるか」「[ 3 ]どういう対応をするか」という内容が盛り込まれています。
また、障害対応方法以外にも、設計時にどんなことを意識するかという内容も書かれています。

CHAPTER-07 障害対策と障害対応

「障害発生した時にスピード解決するために、サーバの状態を把握するための操作は自然に手が動くようにしておきましょう」という内容のChapterです。
すごく実用的で、障害発生時、各調査事項に対してどんなコマンドを実行するのかというのが載っています。
これさ〜〜〜、いっつもなんだったっけって調べるよね〜〜〜〜〜、助かる〜〜〜〜〜、覚えなきゃ〜〜〜〜〜〜〜。
インフラエンジニアの方が実際に利用している重要なコマンドを一括で覚えられるようにしてくれていてとても助かります。

コマンドメモ。見返す。

メモリ搭載量と使用量は？
- # free
パーテーションごとのディスク使用量と空き容量は？
- # df -h
使われているCPUは何で、コア数は全体でいくつか？
- # cat /proc/cpuinfo | grep -e "model name" -e cores
ディスクのRAID構成は？
- # MegaCli -LDInfo -Lall -aall | grel RAID
- # hpssacli ctrl all show config
CPU使用率は高いか低いか？
1. # w
2. # top -d 1
現在のディスクアクセス率は高いか低いか？
- # iostat 1
現在張られているTCPコネクションの数は？
- # netstat -an | grep ESTABLISHED | wc -l
現在サーバにログインしているアカウントは何か？
- # last | grep "still logged in"
サーバが起動してからの経過時間は？
- # uptime
Webサーバの場合、ApacheやNginxなど、何のWebサーバソフトウェアが動いているか？
1. # netstat -lnp | grep 80
2. # ps -ef | grep [プロセス番号]
DBと連携しているWebサーバの場合、何のDBサーバソフトウェアと接続しているか？
- netstat -an | grep ESTABLISHED
- ※ポート番号で判断する。
メモリ / ハードディスク / 電源ユニットが故障していると仮定して、その証拠はどうやって調べるか？
1. # dmesg
2. # more /var/log/messages
サーバにはUSBメモリが接続されているか否か？
1. # dmesg
2. # parted -l
3. # lsusb
ネットワーク機器とサーバのネットワークインターフェースは何Gbpsで接続されているか？
- # ethtool eth0 | grep Speed

おまけ

『インフラエンジニアの教科書2』、「海外での会食の注意」についても載っているので幅が広い
次の日に仕事がちゃんと出来るように飲み過ぎに注意が必要とのこと
— しょぼちむ🏝 (@syobochim) 2020年2月18日

💬 まとめ

「インフラエンジニアの教科書２」は今まで所々で覚えていた知識を体系的に学べる良い本でした。
図解が多くて書き方もわかりやすいのでサクサク読めますが、情報量は多く充実しています。OSやプロトコルの話からRFCの読み方の話まで書いている本ってなかなかないのでは。
利用頻度が高い基本的なコマンドも多く、かつ、実際にインフラエンジニアとして何を検討・対応するのかが書いてあるのも丁寧で嬉しかったです。
インフラの知識に自信がない方に是非お勧めできる一冊でした！

インフラエンジニアの教科書2 スキルアップに効く技術と知識

作者:佐野裕
出版社/メーカー: シーアンドアール研究所
発売日: 2016/08/26
メディア: 単行本（ソフトカバー）

2019-11-27

『技術をつたえるテクニック』は書籍執筆前に読みたい一冊だった

本読んだ

@mochikoAsTechさんが書かれている「技術をつたえるテクニック～分かりやすい書き方・話し方～」という同人誌が、書籍を書く前に本当に出会いたかった一冊でした。
書籍の執筆以外でも仕事やブログなどで文章を書く機会は多くあると思いますし、登壇に関してのノウハウも書かれています。
すぐにでも実戦で使えるテクニックが薄い本にギュッと詰まっていて、サクッと読めるけど学ぶことが多く、すごくオススメです！

booth.pm

📖 目次

Chapter1. 技術を文章で分かりやすくつたえる
- 1.1 読者層をはっきりさせよう
- 1.2 「すんなり入ってくる」ための工夫
- 1.3 一度に沢山のことはつたわらない
- 1.4 事実は時代とともに変わる
- 1.5 分かりやすさを支える統一表記
- 1.6 読者を迷子にさせないで
- 1.7 できるだけ簡潔にしよう
- 1.8 推敲は文章の品質を上げる
Chapter2. 技術を登壇で分かりやすくつたえる
- 2.1 段取り八分現場二分
- 2.2 前に立って話すときのテクニック
- 2.3 つたえるときの心のあり方
Chapter3. 教わり上手をはじめよう
- 3.1 分からないを正直に言うことこそ最初の一歩
- 3.2 地蔵にならず反応を返そう
- 3.3 おわりに

💬 感想

第1章では文章を書く上で、第2章では登壇をする上で、必要となる『テクニック』について書かれています。
本のタイトルにもある『テクニック』という言葉が内容にビッタリと合っていて、意識すれば明日から使える具体的なポイント / 注意点がたくさん書いてあります！
私も以前「いちばんやさしいGit&GitHubの教本」という書籍を書いたのですが、その時にレビューで指摘いただいた内容がとても盛り込まれていました…！くっ…！書籍を書く前に出会っていれば…！

syobochim.hatenablog.com

1.5.4 表記ゆれのチェックはツールでやろう

「いちばんやさしいGit&GitHubの教本」を書いた時にとても便利なツールを教えていただきました。それが「テキスト校正くん」というVisual Studio Codeのプラグインです。
このツールを使うと一般的なルールに基づいた文章チェック（「ですます」調と「である」調の混在など）や、設定した単語の表記ゆれのチェック（「サーバー」と「サーバ」）を自動で実施してくれます。
テキスト校正くん - Visual Studio Marketplace

「技術をつたえるテクニック～分かりやすい書き方・話し方～」でも、ツールでの文章チェックを推奨しています。「テキスト校正くん」と同じような自動で文章チェックをしてくれるツールとして、Visual Studio Codeのプラグインの「vscode-prh-extention」が紹介されていました。
prh - ProofReadingHelper - Visual Studio Marketplace

「いちばんやさしいGit&GitHubの教本」は共著であり、二人の書き言葉の統一をするため、特に表記ゆれのチェックはとても助かりました。
そして、自分一人で書いた文章にも表記ゆれが本当にたくさんあったので、自動チェックまじで大事！！

1.7.1 「ということ」「することができる」は必要？

「ということ」「することができる」を使うと文章が冗長になるので、文章の並び順序を変更したり、冗長な部分を削除して簡潔な文章になるように意識しましょう。

細かいポイントですが、私は特にこの内容が響きました…。
私の書き癖として、「することができる」を無茶苦茶たくさん使ってしまっています…。そして、やはり書籍レビューでも指摘をいただきました。
例えば、以下のような感じ。

before

バイナリファイルでは、git diffコマンドでファイルの変更差分を確認することは出来ません。

after

バイナリファイルではgit diffコマンドでファイルの差分を確認できません。

レビューで指摘されて初めて、この書き方が冗長な表現だと認識しましたし、普段書いている文章にも多用してしまっているなうああ、と…。

💬 まとめ

自分が特に印象に残っている2つの内容を取り上げましたが、それ以外にも書いてあることの多くが実際に書籍レビューにて指摘されました。（なので、この本を読んでいると刺さる部分が多くて心が痛くなる…。w）
執筆前にこの本の内容をしっかり自分の中に落とし込んでいたら指摘数も変わっただろうな…。

そして、冒頭にも書きましたが、文章だけでなく登壇のテクニックについても書かれてあるので活かせるタイミングは多いのではないでしょうか。
この本に書いてあるテクニック自体はそれぞれがすぐに実践できる簡単なものが多いですが、自分の書き癖・登壇時の話癖ってあると思うので、繰り返しInputしたい一冊です。

あ、「【コラム】真面目な後輩に説明を聞いてもらえないのはなぜ？」も、「クゥ…！わかるぜ…！」という内容で面白かったです。

booth.pm

2019-09-09

「GCPの教科書」を読んだよ〜。わかりやすくてボリューミー！

本読んだ GCP

会社の人にオススメいただいた「GCPの教科書」を読みました！
GCPを触って使い心地を楽しみつつ本を読んでいきました。
この本は内容もわかりやすいし、サービスも広く紹介されていて満足度が高い一冊でした！
そして、CLIコマンドも合わせて紹介されているのは嬉しいポイントでした。

GCPの教科書

作者: クラウドエース株式会社吉積礼敏・他
出版社/メーカー: リックテレコム
発売日: 2019/04/19
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

📖 目次と所感

本の目次は以下の通りです。
第3章の基本的なサービス紹介ではCLIでの操作や画面キャプチャが多く、操作をしつつ学んでいくことが出来ました。
第4章〜第5章の高度なサービスはサービス紹介がサラッと書かれていました。
CLIコマンドでの記載があるので、コマンドでの操作になれることが出来るし、サービスも広く知ることが出来るので、GCPの最初の一歩にするのに適した本だと思いました！

第1章　Google Cloud Platformとは？
第2章　GCPの基本を知ろう
第3章　GCPの基本サービスを学ぼう
- Google Compute Engine (GCE)
- Google Cloud Storage (GCS)
- Google App Engine (GAE)
- BigQuery
- Google Cloud SQL
第4章　高度なサービスを知ろう（その１）
- Kubernetes Engine (GKE)
- ネットワーキング
- Bigtable
- Datastore
- Stackdriverモニタリング
- Stackdriverロギング
第5章　高度なサービスを知ろう（その２）
- Deployment Manager
- Cloud Pub/Sub
- Cloud Dataflow
- Dataproc
- Cloud Launcher
- Cloud Functions
- その他サービス
第6章　機械学習
第7章　GCPで使えるAPIの紹介
第8章　AWSユーザーへ
第9章　GCPのまとめと今後の展望

第3章　GCPの基本サービスを学ぼう

GCEのインスタンス作成の速さに感動したんですが、それよりもっと感動が強かったのはApp Engineの使いごこちでした。
App Engineが使いたくてGCPを選択するというケースもあるんだろうなと思うレベル。
デプロイするだけでStackdriverと勝手に連携してくれて、LoggingとTraceが出来るとか最高かよと思いました。

Logging：各言語環境の標準Loggerを使って出力すると、Stackdriver Loggingと自動連携してくれてログを確認出来る。
Trace：実際にどの機能でどのくらい時間がかかっていたか、どのような順番で機能を呼び出していたかを確認出来る。ランダムにサンプルをとって、どのように各機能が呼び出されていたかをグラフィカルに表示してくれる。

さらに感動したのはバージョニングの機能です。
バージョンの切り替えがとても簡単に出来るのでブルーグリーンデプロイが簡単！というだけでなく、トラフィックも簡単に分割出来るので、A/Bテストやカナリアリリースも簡単に実現出来そうでした。
f:id:syobochim:20190909162643p:plain

Google Cloud Storageはアーカイブ用のストレージ（NearlineとColdline）でも、通常のObject Storageと一貫した API を使用することが出来て、かつ1秒未満でアクセスできるというのもすごいと思いました。
使い心地が良さそう。

Google Cloud Storageのオブジェクトの一般公開機能は書籍とは変わっていて、「allUsers」に対して権限を割り当てることで実現可能になっていました。

第4章　高度なサービスを知ろう（その１） / 第5章　高度なサービスを知ろう（その２）

Kubernetes Engineはオートスケールの設定がめちゃくちゃ簡単で使い心地がよかったです。
Marketplaceを活用することで簡単にサービスをデプロイすることも出来ます。
各種チュートリアル：Tutorials | Kubernetes Engine | Google Cloud

Cloud Functionsもチュートリアルがたくさん提供されていました。
Tutorials | Cloud Functions | Google Cloud

第7章　GCPで使えるAPIの紹介

Googleが提供しているAPIを調べられるサイトが紹介されていました。
こういうの結構嬉しい。
Google APIs Explorer

まとめ

「GCPの教科書」を読みました
サービスが広く紹介されていて、GCPの最初の一歩には良さそう
App Engineがすごい

GCPの教科書

作者: クラウドエース株式会社吉積礼敏・他
出版社/メーカー: リックテレコム
発売日: 2019/04/19
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

2019-08-24

Oracle Cloud : Object Storageにファイルを置いたらメール通知させる

OracleCloud

Oracle Cloudでは、

Events：何かアクションが発生した時に他のサービスを呼び出す
Notifications：EmailやPagerDutyへ通知を飛ばす

というサービスが提供されています。
今回は、この2つのサービスを利用して、「Object Storageにファイルを置いたらメール通知される」機能を作ります。
上記の2つのサービスを連携することで、5分程の簡単な設定で作成が完了しました！

公式のドキュメントはこちら

Events：Overview of Events
Notifications：Notifications Overview
Object Storage：Overview of Object Storage

Object Storageを作る
Notificationsを作る＋設定する
Eventsを作る＋設定する
試してみる

2019-08-14

Japan Tour in Summer: Java & k8s on Azure まつりに参加してきたよ！

社外勉強会クラウド Azure Kubernetes Docker

Java女子部とJAZUG女子部のコラボのこちらのイベントに行ってきました〜！

javajo.doorkeeper.jp

イベントは午前の部と午後の部に別れていて、一日丸々参加もできましたが私は午後の部からの参加にしました。

午前の部：コンテナとDockerについて
午後の部：Kubernetesとは&AKSハンズオン

午後に到着した時点で6人程度のチームが4つ作られており、それぞれでチーム名が付いていました。
私は「足引っ張り隊」に合流。良いネーミングですね。笑

4チームそれぞれチーム名が決まりました👏 #てらだよしおまつり #javajo pic.twitter.com/4lU4DNVpLO
— Java女子部 (@java_women) 2019年8月3日

🖥 実施した内容

ハンズオンでは寺田さんがgithubで公開されているこちらのPDFに沿ってハンズオンを進めていきました。
k8s-Azure-Container-Service-AKS--on-Azure/HoL-Contents.pdf at master · yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure · GitHub

自分の中で整理してみましたが、このような構成の構築と操作をしていきました。
f:id:syobochim:20190809170651p:plain

ハンズオンの後はこちらのスライドに沿って、Kubernetesを導入する場合の注意点を寺田さんからお話いただきました。

Japan Container Day 2018 from Yoshio Terada

www.slideshare.net

✨ 印象的だったこと

😀 Docker Imageは小さく作ろう

Docker Imageをなるべく小さくするような工夫の紹介がありました。
例えば、「openjdk:-alpine」を利用するとコンテナイメージを小さくすることができます。
Docker Hub

また、Multi stage buildという機能も活用できます。
実際Multi stage buildを利用しているDockerfileはこちら。
https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure/blob/master/FrontService/1-Dockerfile-Multi
1つのDockerfileにFROM句が2つ書かれていて、ビルド用と実行用のイメージを分けて書いています。

Multi stage buildについてはこの記事の説明がわかりやすかったです。
Docker multi stage buildで変わるDockerfileの常識 - Qiita

また、キャッシュを利用できるように、変更が多く入る箇所についてはDockerfileの後ろの方に書こうというアドバイスもありました。

😀 Serviceを変更するとAKSへ連動される

こちらのServiceファイルのハイライト部分を変更する操作をハンズオンで試しました。
https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure/blob/a1bd6269fbdf064b8e0ba194c3628f573652f4ef/FrontService/11-Service.yaml#L15

以下の部分の記述を

  type: ClusterIP

以下のように変更したのですが、この部分を変えることで、AzureにてLoadBalancerが自動で作られます。

  type: LoadBalancer

この動きについては、こちらのドキュメントに解説が書かれています。
概念 - Azure Kubernetes サービス (AKS) におけるネットワーク | Microsoft Docs

😀 AzureのCLIを叩いた

AKS作成の権限がユーザーに無く、調査している中で、AzureのCLIコマンドを使ってAKSを作成することになりました。
Azureのコマンドはこんな感じです。

$ az login
$ az group create --name myResourceGroup --location japan east
$ az aks create \
    --resource-group myResourceGroup \
    --node-vm-size Standard_DS2_v2 \
    --name myAKSCluster \
    --node-count 1 \
    --enable-addons monitoring,http_application_routing \
    --kubernetes-version 1.13.7 \
    --generate-ssh-keys

1つ目のコマンドでAzureにログインして、
2つ目のコマンドでAKS用のResourceGroupを作り、
3つ目のコマンドでAKSを作成します。

事前にクラウドの管理画面にてAKS作成時の入力項目を見ていたので、3つ目のコマンドのそれぞれのオプションでどんな設定をしているのか、スッと入ってきました。

✨ 最後に

最後のセッションのお話は別のイベントでもお話聞いたことがありましたが、やっぱり寺田さんのお話って面白いです。
特に「技術の勉強は勉強でやったらいいけど、システムに適用する場合は最適なモノを選択しましょう」というような話など、多くの人に聞いてほしい！という内容が多く盛り込まれていました。

運営のみなさま、寺田さん、イベント時間の長い中、お疲れ様でした！
イベント楽しかったです〜！ありがとうございました〜〜！

2019-06-30

他のクラスへの「呼び出し回数」と「引数として渡した値」をテストする

JUnit Java Spring Boot メモ

久しぶりにテストコードを書いたのでMEMO〜。

アプリから他のサービスを使っているけど、自動テストの時はそのサービスを使いたくない。
もしくは、テスト対象のクラスから他のクラスのメソッドを呼び出しているが、他のクラスの仕様はそのクラスのテストに委譲しており、今回のテストには含めたくない。
ただ、作成したクラスからサービスや他のクラスに対して、どんな値が渡されたのかはチェックしたい。

f:id:syobochim:20190630163339p:plain:w500

例えば、Controllerクラスのテストをする場合、 Controller内で Fukuzatsu クラスの hikisuIppai()メソッドを呼び出しているとする。
でも、hikisuIppai()メソッドの挙動は Fukuzatsu クラス側でテストするから、hikisuIppai() メソッドの「呼び出し回数」と「引数として渡された値」が想定通りに設定されていることだけをテストできればOKとする。
そうした時のテストクラスはこんな感じになる。

import com.fasterxml.jackson.databind.ObjectMapper;
import org.junit.jupiter.api.Test;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.mock.mockito.SpyBean;
import org.springframework.test.web.servlet.MockMvc;

import java.math.BigDecimal;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;
import static org.hamcrest.core.Is.is;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.*;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;

@AutoConfigureMockMvc
@SpringBootTest
class ControllerTest {
  @Autowired
  private MockMvc mockMvc;
  @SpyBean
  private Fukuzatsu fukuzatsu;
  @Captor
  private ArgumentCaptor<Hotel> hotel;
  @Captor
  private ArgumentCaptor<Reservation> reservation;

  @Test
  void detailTest(@Autowired ObjectMapper mapper) throws Exception {
    doReturn(null).when(this.fukuzatsu).hikisuIppai(any(), any(), any(), any());

    CreateCommand cmd = new CreateCommand(hoge, fuga, piyo);
    String json = mapper.writeValueAsString(cmd);
    mockMvc.perform(post("/detail").content(json));

    verify(this.fukuzatsu, times(1)).hikisuIppai(any(), hotel.capture(), reservation.capture(), any());
    assertThat(reservation.getValue().getRating(), allOf(greaterThanOrEqualTo(new BigDecimal(0)), lessThanOrEqualTo(new BigDecimal(5))));
    assertThat(reservation.getValue().getNumberOfPeople(), is(greaterThanOrEqualTo(0)));
  }
}

内部の処理をスキップさせるために@SpyBean を利用して Fukuzatsu クラスの hikisuIppai メソッドの処理をモック化している。
今回は、引数に何が来ても null を返すように。

  @SpyBean
  private Fukuzatsu fukuzatsu;

...

    doReturn(null).when(this.fukuzatsu).hikisuIppai(any(), any(), any(), any());

アサーションでは、 hikisuIppai メソッドの呼び出し回数と、引数として渡した値を検査している。
キャプチャできれば普通に is メソッドなどを使って比較ができる。今回は、

hikisuIppaiメソッドの呼び出し回数が1回であること
hikisuIppai メソッドの2番目、3番目に渡した値が想定通りであること
- 2番目の値は hotel プロパティにキャプチャして、 hotel.getValue() で値を取得している。
- 3番目の値は reservation プロパティにキャプチャして、 reservation.getValue() で値を取得している。

を検査している。

  @Captor
  private ArgumentCaptor<Hotel> hotel;
  @Captor
  private ArgumentCaptor<Reservation> reservation;

...

    verify(this.fukuzatsu, times(1)).hikisuIppai(any(), hotel.capture(), reservation.capture(), any());
    assertThat(hotel.getValue().getRating(), allOf(greaterThanOrEqualTo(new BigDecimal(0)), lessThanOrEqualTo(new BigDecimal(5))));
    assertThat(reservation.getValue().getNumberOfPeople(), is(greaterThanOrEqualTo(0)));

2019-06-20

GCPUG Tokyo Next Extended 2019 Infra Dayに参加しました！

社外勉強会 GCP

GCPUG Tokyo Next Extended 2019 Infra Dayに参加しました！
スライドまとめとMEMOです。

イベントページはこちら
gcpug-tokyo.connpass.com

Next Introduction

スピーカー：しんめたる (@sinmetal) | Twitter さん
内容：Google Cloud Next SF19のイベントレポート

スライド

docs.google.com

Google Cloud Next SF19のセッション内容はYouTubeで公開されており、記事にもまとめられている。
Google Cloud Platform - YouTube
Google Cloud Japan 公式ブログ: Google Cloud Next ’19 で行った 122 の発表

Session1

スピーカー：しんめたる (@sinmetal) | Twitter さん
内容：Google Cloud Next SF19でのリリース内容まとめ

スライド

docs.google.com

ベンダーが提供したサービスを使えるようになって、請求はGCPに統合される。
2019年いっぱいで提供されていく予定とのこと！

Confluent
DataStax
Elastic
InfluxData
MongoDB
Neo4j
Redis Labs

こんなサービスのアップデートも紹介されていました！
FirestoreとBigtableはどういう使い分けなんだろう。。。NoSQLのベストな使い道もわからない。。。勉強したい。。。

Cloud SQL
- Cloud SQL - MySQL & PostgreSQL Relational Database Service | Cloud SQL | Google Cloud
  - PostgreSQL、MySQL、SQL Server のリレーショナルDB
Firestore
- Cloud Firestore | Firebase
  - スケーラブルなNoSQL クラウドDB
Bigtable
- Cloud Bigtable の概要 | Cloud Bigtable ドキュメント | Google Cloud
  - 分散型 NoSQL データベース

Session2

スピーカー Jun Sakata (@sakajunquality) | Twitter さん
内容：Service Meshの説明とTraffic Directorについて

スライド

未公開

なぜService Meshをしたいのか

Observability
- 全てのトラフィックがenvoyを経由することで、ステータスやレイテンシ、トラフィック量などを管理することができる
Reliability
- ヘルスチェックをした上でロードバランサー的にトラフィックを制御できる
- リトライやタイムアウトなどの設定を集中管理できる
Security
- Mutual TLS
- このサービスにはここから通信していいという設定ができる

などのメリットがある。

"Decouples developers from operations"
「開発者をオペレーションから切り離して、開発者はビジネスロジックに集中できる」

Traffic Director | Google CloudにはIstioのAPIが全て実装される予定。2019/7の予定だったはずだが、現時点では対応時期は未定。
Traffic Directorを利用するとサービスネットワーク構造を可視化できる。
Traffic DirectorとStackdriver（GCPのモニタリングサービス）と連携することで、サービス状況が把握しやすくなる。

現時点でIstioを利用した場合は Istio on GKEを選択するのがオススメとのこと。
Istio on GKEで構築すれば、GCP上のL4ロードバランサーを自動でプロビジョニングしてくれる。
OSS版は自分たちでマネージしなければいけないので、ハードルがある。
Trafic Directorにはまだα版の機能が多いので、まだプロダクションレディではない。

Istio 1.0.xとIstio 1.1.xはかなり動作が違う。
接続先をすべて設定していく必要があったが、1.1.Xからは基本すべて許可になったため、サービスメッシュをやる障壁が1.1.xで下がった。
外部のサービス（DataDogなど）とhttpsとつなぐ時は注意が必要。
バージョンの互換を検証してくれるものもある Upgrading Istio on GKE | Istio on GKE | Google Cloud

パネルディスカッションには残念ながら参加できずでした。
会場に飲み物やポテチなどが置いてあった…！
イベント運営の皆さま、ありがとうございました！🙇‍♂️✨

そこに仁義はあるのか(仮)

略してそこ仁！

インフラエンジニアの必須知識を広く体系的に学べる「インフラエンジニアの教科書２」を読んだ

📖 目次

「インフラエンジニアの〇〇」

「主に監視するのはdiscatd(packet loss)とunbind」

CHAPTER-07 障害対策と障害対応

コマンドメモ。見返す。

おまけ

💬 まとめ

『技術をつたえるテクニック』は書籍執筆前に読みたい一冊だった

📖 目次

💬 感想

1.5.4 表記ゆれのチェックはツールでやろう

1.7.1 「ということ」「することができる」は必要？

💬 まとめ

「GCPの教科書」を読んだよ〜。わかりやすくてボリューミー！

📖 目次と所感

第3章　GCPの基本サービスを学ぼう

第4章　高度なサービスを知ろう（その１） / 第5章　高度なサービスを知ろう（その２）

第7章　GCPで使えるAPIの紹介

まとめ

Oracle Cloud : Object Storageにファイルを置いたらメール通知させる

Japan Tour in Summer: Java & k8s on Azure まつりに参加してきたよ！

🖥 実施した内容

✨ 印象的だったこと

😀 Docker Imageは小さく作ろう

😀 Serviceを変更するとAKSへ連動される

😀 AzureのCLIを叩いた

✨ 最後に

他のクラスへの「呼び出し回数」と「引数として渡した値」をテストする

GCPUG Tokyo Next Extended 2019 Infra Dayに参加しました！

Next Introduction

スライド

Session1

スライド

Session2

スライド

📖 目次

「インフラエンジニアの〇〇」

「主に監視するのはdiscatd(packet loss)とunbind」

CHAPTER-07 障害対策と障害対応

コマンドメモ。見返す。

おまけ

💬 まとめ

📖 目次

💬 感想

1.5.4 表記ゆれのチェックはツールでやろう

1.7.1 「ということ」「することができる」は必要？

💬 まとめ

📖 目次と所感

第3章 GCPの基本サービスを学ぼう

第4章 高度なサービスを知ろう（その１） / 第5章 高度なサービスを知ろう（その２）

第7章 GCPで使えるAPIの紹介

まとめ

🖥 実施した内容

✨ 印象的だったこと

😀 Docker Imageは小さく作ろう

😀 Serviceを変更するとAKSへ連動される

😀 AzureのCLIを叩いた

✨ 最後に

Next Introduction

スライド

Session1

スライド

Session2

スライド

第3章　GCPの基本サービスを学ぼう

第4章　高度なサービスを知ろう（その１） / 第5章　高度なサービスを知ろう（その２）

第7章　GCPで使えるAPIの紹介