mkurokiのメモ

mkurokiのインフラとか仕事とか色々なメモ書きです。ここで書いている主張等は所属する会社とは関係がありません

Kubernetes完全ガイド(第2版)を読んだので感想とか

はじめに

こんにちは、mkurokiです。 タイトルの通りですが、Kubernetes完全ガイド(第2版)を読んだので、勉強になったポイントや参考になったポイント、感想などを章ごとにまとめて書いてみたいと思います。

最初にこれだけは書いておきますが、めっちゃいい本でした!

第1章 Dockerの復習と「Hello, Kubernetes

Dockerの基本が復習という形で書いてある。Dockerの仕組みやビルドの方法、各種ベースイメージの違いなども解説されている。基本を忘れてしまったら読み返したい。

第2章 なぜKubernetesが必要なのか?

k8sの概要として歴史と特徴が書かれている。 k8sを使うと何ができるのか:コードでの管理、オートスケーリング、スケジューリング、リソース管理、ロードバランシング、データの管理 etc… k8sに対応した連携システム・ミドルウェアの紹介も。

第3章 Kubernetes環境の選択肢

どのようなプラットフォームでk8sを利用する選択肢があるのか:

  • ローカルk8s:Minikube等。手元のマシン上で気軽に試せる
  • k8s構築ツール:kubeadm等。ツールを利用して任意の環境に構築
  • マネージドk8sサービス:GKE,EKS等。パブリッククラウド上で提供される

ローカルk8sは本番環境には適さない。

また、少なくともステージングとプロダクションでは同じ環境で揃えられるようにしておくとよい。

その他、k8sのサービスレベル目標(SLO)が満たせるクラスタの上限構成や、ブラウザ上で手軽に試せる k8s プレイグラウンドの紹介も。

第4章 APIリソースと kubectl

k8sの基礎、リソースとAPIリファレンス、kubectlの使い方など。

createではなくapplyを使う理由、アノテーションとラベルの解説、ログやデバッグなども含めオペレーションの基礎が詰まっている。

第5章 Workloads APIs カテゴリ

クラスタ上にコンテナを起動させる各種リソース(Pod,ReplicaSet,DaemonSet等)の解説。ReplicaSetはDeployment経由で使うのを推奨。k8sを運用する上では基本となるリソースの使い分け方で、内容もなかなかボリューミィ。

なお、この章で妙に印象的だったのがPodのDNS設定(spec.dnsPolicy)。

PodのDNS問い合わせの挙動を定義するのだが、デフォルトだと設定値「ClusterFirst」となるのに対し、それとは別で「Default」という値も設定できる。

Defaultはデフォルトの値ではないので注意が必要(ぐるぐる目)というなんとも不思議な設定値……。

第6章 Service APIsカテゴリ

ServiceリソースはPodのサービスディスカバリやL4バランシングを提供している:ClusterIPやLoadBalancer等。

似ているがIngressはL7を提供するサービス:クラスタ外のGCLB等を使う物と、クラスタ内にデプロイするNginx Ingressがある。

第7章 Config & Storage APIsカテゴリ

環境変数を利用した設定、機密情報を読み込むためのSecretリソース、key-valueで設定情報を保存しておくConfigMapリソースなど各種の利用方法。

PersistentVolumeClaimを使った永続化ボリュームの要求方法と、ディスクの拡張・subPathなどの紹介も。

第8章 Cluster APIsカテゴリとMetadata APIsカテゴリ

短い章で、ほぼ両カテゴリの概要の紹介とNodeリソース、Namespaceリソースの紹介。他の項目については次章以降で後述するということが書かれている。

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

Podの最低Requestsと上限Limitsを適切に設定すること、それによるQoS Classの適用、LimitRangeとResourceQuotaによる制限。

オートスケーリングの方法としてクラスタ自体のCluster AutoscalerとPodのHorizontal/Vertical Autoscalerの選択肢が紹介されている。

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

Liveness Probe、Readiness Probe、Startup Probe の 3種類のヘルスチェックの種類と、それぞれに用意されているexec/httpGet/tcpSocketのヘルスチェック手法。

コンテナ起動時と終了時のスクリプト実行、initContainers、終了処理のタイミングなど。

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

ノードを停止するためスケジューリング対象から除外するkubectl cordonコマンド、ノード上で実行中のPodを排出するdrain処理、PodDisruptionBudgetによる制御などの紹介。

Podを気軽に再起動できるようにしておくとメンテナンスの省力化に繋がる。

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

Podの配置先Nodeを決定するために柔軟なスケジューリングが可能。

特定のノード上だけで/除外して実行する、特定のPodがいる/いないドメイン上で実行する、など。

実践的には、Nodeに付与したラベルとの組み合わせで、GPU使用とか本番環境とかの指定ができそう。

故障中ラベルを付けるとかも、かなり実際の運用で使われそうな内容で、なるほどーとなった。

第13章 セキュリティ

正直この章はふんわりとした理解……必要になったらまた読み返したい。 UserAccount と ServiceAccount の違い、RBAC、ClusterRole と ClusterRoleBinding、ネットワークに制限をかける手法、kubesecによるSecretリソースの暗号化の手法など。

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

システムが大規模化したときの管理を助けてくれる代表的なツール、HelmとKustomizeの紹介。

Helmはk8sのパッケージマネージャ。chartとしてパッケージのinstall情報を管理してくれる。

Kustomizeはテンプレートから環境別にフィールドを上書きして、productionやstaging環境ごとにレプリカ数やCPU/memoryなどのリソースを変更するといったことが実現できる。

Ksonnetは今は開発が停止しているので使わないほうが良さそう。

第15章 モニタリング

DatadogとPrometheusの使い分け。

Datadogはノード上でDaemonsetで起動(もしくはサイドカー)、アラーティングも。余談だけどダッシュボードかっこいいなこれ。

Prometheusではマシンを用意すれば課金要素なし、Pull型なのでExporter経由でデータ取得したり。可視化はGrafana経由で。

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

アプリケーションのログは基本的には標準(エラー)出力に出すべき、安定保存にはFluentdがおすすめ。転送先は各クラウドのマネージドサービス利用など。Fluent Bit もある。

もしくはDatadog Logs、Grafana Loki なども。集約して利便性を高めることが大事。

第17章 Kubernetes環境でのCI/CD

実運用では手動でのkubectl実行は可能な限り避けるべきで、そのためにGitOps、自動CI/CDの仕組みが必要。

  • CIツール:TektonやKaniko等、チェックにはKubeval、Conftest、Open Policy Agent/Gatekeeper
  • CDツール:ArgoCD:KustomizeやHelmのマニフェストも扱えるため完成度が高い

開発環境を整えるツールとしてTelepresense、Skaffoldなど。

このへんの、Kubernetes周辺のエコシステムはほんとに進化が早そうなところ。各システムの公式ドキュメント要チェック。

改めて手動オペレーションの排除は大事……。

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

k8sはマイクロサービスアーキテクチャと相性が良い。そのモニタリングのためにサービスメッシュがある。

代表的なプロダクトIstioではPodにサイドカーとしてEnvoyプロキシを埋め込み、トラフィックコントロール、通信の暗号化などが可能に。

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

k8sを構成するetcd,kube-apiserverなどの説明。独自のリソースを追加して拡張もできるようになっている。

本の内容から逸れて余談(僕の見解)だが、このあたりはkubernetes the hard wayをやるとわりかし理解が深まるような気がする。

t.co

第20章 Kubernetesとこれから

CNCFによる開発と標準化、k8s上に展開するXaaSやKnativeなど周辺のエコシステム、動作確認のためのtestbedなどの紹介。

付録・あとがき

最後に、逆引き的にめちゃめちゃ便利な付録のFAQと、あとがき。

あとがきも短いながら沁みる内容となっていた。内容は是非キミの目で確かめてほしい(

まとめ

というわけでめっっっちゃ時間かかってしまった(2ヶ月ちょいかかった)けど読了!しかしこれで終わりではなく、触りながらまた読み返して理解を深めることになるだろうなぁ。

しかし流石はというかKubernetes完全ガイド、完全にガイドしていくぞという気概のようなものを読んでいて感じます。看板に偽りなし感。Kubernetesの入り口として、とてもよいものだと思いました。

なお、この記事は Twitter に書き溜めておいた章ごとのメモをまとめただけというものなのでたいへん楽でした。 読むのに時間がかかりそうな本は、少しずつでも読んで得た内容を記録しておくと思い出しやすくて良いかもしれません。

36歳父親のエンジニアが転職をして気づいたこと

こんにちは、mkurokiです。

はじめに

実は今年転職をしまして、ゲームインフラという領域は変わらないのですが、勤める会社が変わりました。

転職をするのは3回目、新卒で入った会社から数えて4社目になります。

// Job Hopper とまではいかないかと思いますが、まぁまぁの転職回数になってきましたね。

36歳で転職をした共働き父親エンジニア/マネージャーという立場から、このタイミングで転職をするとどんな事が起こるのか、転職によって気づいたことなどを書いてみたいと思います。

もし似たような境遇で転職を考えている方の参考になりましたら幸いです。

※ 広義のソフトウェアエンジニアという意味で「エンジニア」という単語を使っています。

なぜ転職をしたか

転職の目的としては

  • 一度マネージャーからプレイヤーに戻り、技術的な領域を伸ばしたい

というところです。僕は前職で4年ほどインフラチームのマネージャーを務めていましたが、一旦ある程度マネージャーとしてやれることはやれたかなと感じ、一段落したところで、これから先の自分のキャリアをどう積んでいくかを考えました。

おそらく最終的にはマネージャー方向に進むことにはなるかなと思いつつ、そこへ進んでいくための基礎力の一つとして、現状は技術力が手薄になっているな、と感じました。

そして、技術力が手薄になっている部分を補強したいと感じ、実際に手を動かすプレイヤーとして再度経験を積みたいと考えました。 (機会があれば、マネージャーとしてチャレンジした内容もどこかで記事にまとめてみたいです)

前職の会社では、残念ながらプレイヤーに戻ることはできませんでしたので チャレンジを含めて受け入れてくれた今の会社には感謝しています。

内定を頂いた会社はいくつかありましたが、楽しくゲーム作りのお手伝いができそうな会社、という点で魅力的でしたので今の会社を選びました。

また、たまたま知り合いで転職先の会社のOBの方もいましたので、この会社がどんな雰囲気なのか、自分にフィットしそうか、アドバイスを頂くこともできました。

人とのつながりがあると色々といいことがあるなぁと実感した次第です。

転職をしてみて

転職で大きく変化したこと

そして、その転職でどんな変化があったかというと、大きくは2つです。

  • マネージャーからプレイヤーになった
  • 中堅規模の会社から、より大きな規模の会社になった

といった変化がありました。まぁ当然勤務地なども変わってはいますが、細かいところは割愛。

余談ですが前職の最後は5月末最終出社という時期で、緊急事態宣言の真っ最中。ほぼ100%リモートワークで勤務していました。

最終出社日だけは、荷物などもありましたので物理的に出社しましたが、まぁ当然というかこのご時世のため送別会などはありませんでした。寂しい〜。

転職先での初出社は7月1日、入社後すぐにリモート比率高めでの勤務が始まりました。

36歳父で転職をして気づいたこと

若い頃の転職と比べると、家庭があり、子どもがあり、持ち家があり と 様々な面で転職が大変になってきているところがあるなぁという気がしました。

生活水準を変えないようにと考えると、給与を下げるという選択もしづらいですしね。

逆に言うと、家庭や子どもがいても働きやすい環境の会社であれば転職のハードルが下がりますので、ミドル層の中途採用を増やしたい企業には、こういった施策がプラスになるのではないかと思います。

以下、36歳の転職で感じたこと・気づいたことを箇条書きで書きます。

有休日数がどかっと減るのでがなかなかカツカツ

子どものいる家庭は、子の体調不良や、保育園の面談などで平日の休みが発生しがちですが 転職前なら潤沢にあった有給休暇が転職のタイミングでガッツリ減るので、結構カツカツになるなぁということがありました。

前職では「なんかあったら有休いっぱいあるし」で安心を得られていた部分は結構あったのかもなぁと気づきましたね。

有休復活まであとnヶ月で、残り日数があと何日だから、だいたい一月あたりx日か……みたいな計算を久しぶりにした気がします。

まぁでも、リモートワークと柔軟な働き方のおかげで、大したことのない用事(郵便物を出すとか、荷物を受け取るとか)で有休を使うことが減っているのでなんとかなっているかなと思います。

看護休暇みたいな制度もあるので助かってますし、そんなに心配はしていません。

逆に言うとこういった制度や働き方が充実した企業でなかったら、ちょっと辛かったかもしれません。

採用前に調べて/聞いておくとよさそうです。

リモートでの on boarding 大変

これはなかなか各社どこも苦労されているところではないかと思いますが、リモートでの on boarding は、やはりけっこう大変だったなと感じます。

リアルでの飲み会などもなかなか開催できず、オフィスに行ってもほとんどのチームメンバーは在宅なので、結局いまだに直接顔を合わせたことのないチームメンバーも結構います。

そんな中で信頼関係を築いて(ちゃんと信頼関係を築けているかはあまり自信がありませんが)一緒に仕事をする同僚としてチームに入っていく関係性を作っていくのは、なかなか大変でしたし結構時間もかかったかなと感じています。

コミュニケーションを増やすためにやってよかったことはいくつかあるのですが、その筆頭として、Slackの個人times channelを作ったことが個人的にはだいぶプラスに働いた気がします。

times channelで僕がアホなことを言っても、暖かく接してくれている同僚のみなさんのおかげでなんとかやっていけております。

マネージャーからエンジニアに戻るの結構大変

これはもうひとえに僕の実力不足のせいですが、コーディングや手を動かす場面、また業務上の技術的な問題解決にかなり時間がかかったり苦労したりしています。

転職先はそれなりに大きな企業でもあり、長年運用されてきたシステムもあり、ドメイン知識が必要な場面も多々あるのですが、そこも不足している上に技術的な力も足りてないので、まぁやっぱりある程度覚悟はしていましたが大変ですね。

これについては難易度の高くなさそうな課題から担当させてもらったり、プロジェクトに入る際に、インフラサイドのProject Managerに近い立場で入らせてもらい、得意分野を活かしながら技術を吸収させてもらうことでなんとかなっています。

理解のあるマネージャーや技術リーダーに感謝です。

家庭にもリソースを割かねばならない

こちらは僕の在宅勤務の環境上のこともありますが、定時を回ったあたりになると、家の中のload averageが上がり始め、子の夕飯風呂歯磨き寝かしつけみたいなタスクがわんさか出現します。

「これはワイも1coreとして稼働せねば処理が詰まってしまう!」みたいな状況が発生し始めるので、「残業をいっぱいしてどうにかする」みたいな手法が少々取りづらい環境になっています。

幸いにもフレキシブルな働き方ができる雇用条件になっていますので、一旦離席して子の風呂上がりを受け取り、保湿クリームを塗り、服を着せ、髪を乾かし、絵本を読み、妻にパスして業務に戻る、みたいなことも可能なので、そういったやり方もたまにしています。

共働きなのでできる限り妻の家事育児の負担量を減らしたいのですが、まぁ平日離席してのタスクは流石に上記くらいが限界なので、退勤後に洗濯をしたり、朝の保育園送りをするのとあとは土日の家事育児ボリュームを上げて、バランスを取ることを目指しています(それでもトータルはやっぱり妻の負担分がでかい)。

なるべく業務時間中の効率を上げるようがんばります。

健康を維持するの大事

現在37歳の僕は完全に中年男性目前なのでうっかりすると体重が増え、中性脂肪が増え、LDLコレステロールが増え、健康診断の結果に黄色信号が発生します。

健康を維持しないと質の高い労働を維持することもできず、ひいては家庭を維持する事もできませんので、体重を含めた健康管理も重要です。

転職後、なかなか運動や筋トレに時間を割くリズムが掴めず、体重は増加傾向にありました。

これはなんとかせねばと思い、まずは「運動をするぞ」という決断をせずとも運動ができる仕組みづくりから(決断はコストが高い)ということで、下記のようなルーチンを設定してみました。

  • 月曜日:筋肉体操を1セットやる
  • 火曜日:プランクと朝ウォーキングをする
  • 水曜日:昼食を軽めにする
  • 木曜日:休肝日+リングフィットアドベンチャーやる
  • 金曜日:プランクと朝ウォーキングをする

というゆるい目標を設定してなんとか体重を押し留めています。土日は子どもと遊ぶところにパワーを持っていかれるので設定なしです。

もうちょい続けて、長期的なスパンで1ヶ月1kgくらい減ればええやろ、という感じにしたいです。

中長期的な目標を考えるのも大事そう

転職後に初めての目標設定を行う際、改めて今後どのような成長をしていきたいか、どんなキャリアを積みたいかを考えました。

やはりある程度のロードマップというか、マイルストンを設定してあと何年後にこうなっていたい、なのでそれまでの目標をこう設定する みたいな努力の方向性の定義をするのは有効そうだと思いました。

まぁありふれたやり方ではありますが、意識はしておきたいなという感じです。

おわりに

36歳父親のエンジニアが転職をして気づいたことはそんな感じです。読んでいただいてありがとうございました。

似たような境遇の方がどれくらいいるのかはわかりませんが、SDGsの目標を意識せざるを得ない社会になっていく流れはあるかと思いますので、家庭と仕事どちらも継続的な成長をするためにどういったアプローチができそうかを考えることは有用なことのような気がしています。

いい人生になるように少しでも前に進みたいですね。

「Webエンジニアのための監視システム実装ガイド」を読んだ

book.mynavi.jp

表題の書籍を読みましたので、本の紹介や感想などを書いてみたいと思います。

どんなことが書いてあるのか

  • 現代のWebシステムに必要な監視のシステムについて、概要から選定・導入の方法や運用まで、「監視」に必要な情報が一通り揃っています
  • 一冊通して読むことで、実践的・現代的な監視システムの全貌を把握することができると思います

以下、チャプターごとの内容を少し紹介

チャプター1:監視テクノロジの動向

  • 少し前のスタイルの監視から現代に至るまでの、監視システムがどのように移り変わってきたかの変遷を知ることができます

チャプター2:監視テクノロジの概要

  • どのような手法やツールを用いて監視をするかが書かれています

チャプター3:監視テクノロジの基礎

  • 前述の概要について、構成要素の基礎技術が解説されています

チャプター4:監視テクノロジの導入

  • どのように監視を始めるのか、またどのように監視ツールを選定するのか等が解説されています

チャプター5:監視テクノロジの実装

  • 特に重要な監視項目などの具体例や、監視対象別のTipsなどが書かれています

チャプター6:インシデント対応実践編

  • インシデント対応の実践において、基礎知識や心構え、ふりかえりの方法などが書かれています

チャプター7:監視構成例

読んでみての感想など

  • 現代的な監視とはどういうものか、どのように実装されるのかについて幅広く知識を得ることができる本だと思いました。特に現場目線というか、MSPの会社で鍛え上げられまくった貴重なノウハウが詰まっていると思います
  • さすがに、細かなミドルウェアや言語ごとの詳細な監視パラメータなどまで網羅はされていませんが(ページ数がいくらあっても足りない)、参考になる情報やリンクなどでのフォローも手厚く書かれているため、それをもとに調べていく事もでき、困らなさそうです
  • 古くからの監視システムの知識を現代向けにアップデートしたい方向けにも、入門 監視と同様、おすすめできると思います

というわけで、「Webエンジニアのための監視システム実装ガイド」を読んでみて でした。システムをどう監視していくかというところは、単純な正解がないことも多いので悩ましい場面もあるかと思いますが、悩んだ際に指標になる内容が多かったように感じます。監視で悩んだらまた読み返してみたいと思います!

AWSのSpot InstanceとAurora Serverlessで個人環境のTCOを最小化したい話

こんばんは、mkurokiです

個人的な/私用の 環境って持ってる人も多いかと思うんですが、 お金を稼ぐためのものではなかったりすると思いますので できるだけそこにかかるコストは最小化したいですよね?

今回はそのへんをうまいこと調整してみたいなーと思い、やってみた話です。  

要約

  • Spot Instance で 仮想マシンTCOを最小化してみる
  • Aurora Serverless でDBのTCOを最小化してみる

解決したい課題・要件

  • 個人用の環境のTCO(Total Cost of Ownership)を最小化する
    • 前述の通り、金も手間もかけずにいい感じの環境を目指す
  • DBの面倒をなるべく見ないで済むようにする
    • サーバー費節約のためAllInOneサーバーになにもかもすべてを同居させてしまうと、事あるごとにMySQLがOOMに殺されるので、そのような事態を避け、DBのお世話にかかる手間を小さくしたい
  • 主にフロント用途で仮想マシンは1台稼働させる

前提条件

  • 単純なWEB(apache)とDB(MySQL)のサーバーシステムの個人的な環境
  • 一応外部に公開しているサービスが動いている
  • そんなにミッションクリティカルでもなく、止まるとめっちゃ困るわけでもなく、ゆるく触りたいけど金と手間をなるべくかけたくない環境
  • けどそんなに頻繁に長いこと止まられるとちょっと嫌だなーという環境
  • クラウドサービスはどこでもいいといえばいいんだけど、今回はAWS

割り切った部分

  • レスポンスタイムは多少遅くても良い
  • 可用性はそんなに重要視しない

 

採用した構成

  • EC2 t3.small スポットインスタンス + Aurora Serverless
    • 可用性を重視しないためスポットインスタンスの瞬断を許容し、費用を抑える
    • DBへのアクセスも少ないし初回起動時に時間がかかっても大して困らないため、Aurora Serverless で必要なときに必要なだけDBのリソースを使い、管理を気にしなくて良い構成へ

結果

  • 費用はこんな感じになった
    f:id:mkuroki24sp:20200702235654p:plain
    コストの推移グラフ
    • 上記グラフの①のあたりで構成を切り替えて、今回導入の「スポットインスタンス + Aurora Serverless構成」に変更した
    • ②の期間中は、Aurora Serverless の設定がマズくて費用が高くなってた。後述する
    • ③のあたりが平常時の平均的なコスト。
      • 一日$0.66(≒月$19.99)くらいにおさまる感じ(おさまってくれ頼む)
  • Aurora Serverless は最初、常に1インスタンス立ち上がりっぱなしの設定になっていたため、費用がかさんでいた(②の期間)
    • 下記にチェックを入れないと、アイドル時に費用を抑えることができない
      f:id:mkuroki24sp:20200703000351p:plain
      ここにチェック

念のため、予算アラートの設定

  • とはいえ、Aurora Serverless がアクセスに応じて費用が増えまくる可能性はあるため、月額の費用がある程度の金額を超えたらアラートを出すように設定しました
  • 請求ダッシュボード→Budgets から予算とアラートを設定できます。個人のメールでアラートを受信するようにしました
    f:id:mkuroki24sp:20200703001414p:plain
    予算アラート設定

まとめ

というわけで、いい感じのそこそこ安くて使える環境になったような気がします。 監視周りをもうちょっと整えていきたいところですが、続きはまた次回!

在宅勤務のパフォーマンスを最大化するために

こんばんは、mkurokiです

在宅勤務が日常的になってきている職場もあると思います。

仕事の中で、在宅勤務がどうすればうまく進むか・パフォーマンスを最大化できるか といったところを検討してきたので、メモ代わりではないですが書き残しておいてみたいと思います。

環境設備・ツール・ビデオ会議(ビデオチャット)Tipsの3つのカテゴリで分けて記載します。

 

1. 環境・設備面

在宅勤務のために必要な設備や環境について

必須で必要なものから、あると便利なものまで

 

  • 必須で必要なもの
      • 家がないと在宅が出来ない
    • 電源
      • PCを動かすために必要
      • 意外と作業場所との兼ね合いでコンセント位置が悩ましいこともある
    • PC
      • おそらくほとんどの人が、PCがないと仕事ができないと思われる
      • 会社貸与のノートPC、もしくは自宅のPC
      • もしくは会社から自宅へ送付したPC
    • インターネット回線
      • 可能なら高速で安定した回線
      • さらに可能なら1Gbps以上の有線接続
    • VPNもしくはRDP環境
    • 家族の理解
      • 家で仕事をしているときは基本的に他のことが出来ない、
        ということを家族と共有し、理解を得ておくとスムーズに進む
      • ただ、自治体・保育園・教育機関の都合などで在宅勤務をしながら子の面倒を見ないといけない、等の場合は家族でサポートし合う必要がある
      • その際、会社側の理解および周囲のメンバーにそのことを伝え、理解を得られておくと望ましい。周囲のメンバーがそれをある程度柔軟に許容できる環境であるとよい
  • あると望ましいもの
    • 個別の部屋 個室
      • ビデオ会議時など、他の家族や物音の混入が避けられ、快適
      • 一人暮らしであればおそらく問題ない
      • 一人暮らしでも、壁が薄い問題が発生する場合がある
    • ある程度いい椅子・デスク
      • 長時間座っても身体への負担が少ないものがあるとよい
    • サブモニター
      • ディスプレイが複数あるとやはり作業の効率が良い
    • PCカメラ(WEBカメラ)・マイク
      • ビデオ会議で使用。会社スマホなどでも代替可能
      • いいものがあると気分が良くなる
    • イヤホン・ヘッドホン
      • ビデオ会議時、イヤホン/ヘッドホンを使用することで
        スピーカーからの音をマイクで拾うことがなくなり、
        通話のクオリティが格段に上がることが多い
        個人的には必須レベルでおすすめしたい
      • ビデオ会議ツールによっては、あんまり変わらないかも?
  • あったら便利なもの
    • 外付けマウス・キーボード
      • 好みで

 

2. ツール

  • ビデオ会議ツールを選択する
    • Google Meet
      • 必要十分な機能を持つ
      • セキュリティ的な懸念がなさそう
    • Zoom
      • 人気がある、機能が充実している
      • バーチャル背景で部屋を隠せる
  • チャットツールを選択する
    • Hangouts Chat / Slack / Chatwork / Teems など
    • 正直なんでもよい。統一されていることのほうが望ましい
    • チャットツール利用のガイドラインが定まっているとよい

 

3. ビデオ会議をよりよいものにするために

直接対面でのコミュニケーションが取れないので、ビデオ会議を上手く使うことで有効なコミュニケーションに繋げることが出来ます

その際のTipsをいくつか

 

  • イヤホン/ヘッドホンを使用する
    • 前述の通り、通話の品質がぐっと上がる
  • 話さないときはマイクをオフにする
    • タイピングの音や、家の外を走る車の音などが意外とうるさかったりして
      それらを防ぐことが出来る
    • 話すときにマイクをオンにするのを忘れがちだが、
      Meetであればマイクオフで喋ってるよ、と表示してくれるので気づきやすい
  • 画面共有を利用する
    • 同じものを見ながら話すことで、認識のズレが少なくなる
  • ホワイトボード系のツールを併用する
    • GoogleのツールであればJamboardなど
    • 同じものを見ながら話すことで、認識のズレが少なくなる
  • 議事録を取りながら会議を進めて、会議が終わったら共有する
    • オフィスでの仕事以上に、情報の可視化と共有が大事になる
    • 必要な情報が行き届かない人がいないように全員が意識するとよい
    • Google Docsなどリアルタイムで複数人が編集できるドキュメントを活用すると、議事録作成が効率よく進む

まとめ

在宅勤務のやりかたは会社の数だけあると思うので、上記に色々と書いてはみたけれど、正直答えは人によってバラバラだと思う。

結局は組織に蓄積していくノウハウが大きい、もしくはノウハウの蓄積ができる環境になっているかどうかというところがものを言うかもしれない。

上記は既に動いているチームの駆動を前提としたもので、チームビルディング過程のチームや新しくメンバーがジョインしたばかりのチームにおいてはテレワークでの関係構築はなかなか難しいところだと思う。課題として残してトライアンドエラーで良い方法を見つけていきたい。

人間の生きる環境は様々なので、他者の人生と環境にどれだけ想像力をもって相互理解の手を伸ばせるメンバーが集っているかどうか、およびチームのマネージャーがそういうチームを作れているかが大事になってくるのかなー。

AWS 認定資格 Solution Architect - Associateを取得した話

こんばんは、mkurokiです。

f:id:mkuroki24sp:20200105010027p:plain

先日、AWS 認定資格の Solution Architect Associate (通称SAA)を取得してきました!
ので、その時の話を書いてみます。

 

どんな資格なのか

 AWS 認定ソリューションアーキテクト – アソシエイト試験は、AWS における分散システムの可用性、コスト効率、高耐障害性およびスケーラビリティの設計に関する 1 年以上の実務経験を持つソリューションアーキテクト担当者を対象としています。

https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

 とのことで、上位のProfessionalと比べてやや難易度は低いものの、AWSにおける重要なポイントを抑えられているかが問われる試験となっているようです。

受験料は税込16500円でした。

 

なぜ取得したか

以前GCPの Associate Cloud Engineer は取得していたのですが、業務上はAWSを利用する必要もあり、より幅広い観点で最適なアーキテクチャの提案ができるように、またその裏付け・説得力としての認定資格があるといいかな、と考え、試験を受けました。

 

どのように勉強したか

SAA資格取得のための勉強を始める前の、AWSについての知識量としては、業務で多少嗜んだ程度ですが、AWS Summitなどに参加してレポートをまとめていたり、GCPで学んだ知識も多少はありましたので、そのあたりはまぁ役には立ったかと思います。

もともとインフラエンジニアとしては8年くらいなんとなくやってますので、インフラ的な知識は持っていました。

資格取得のためにやったこととしては、下記の2点です

1. 本を買って読んだ

いわゆる「黒本」と呼ばれているこちらですね

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書

 

模擬試験1回分の問題と回答がオンラインで得られるのでお得です。
こちらの本は熟読したというよりは、各章の練習問題を解き、間違っていたところを復習して、苦手な部分を強化する といったような使い方がメインでした。

2. 付録の模擬試験を解いてみた

上記黒本の模擬試験を解いてみて、間違っていたところを復習しました。
この時点で、おおむね8割程度の正答率は得られていたので、まぁ大丈夫だろうと思い、それ以上はあまり勉強してません。

 

全体を通しての勉強時間は10時間なかったかな、というくらいでした。

 

試験当日 

池袋のテストセンターで受験しました。
まず全部の問題を解いていって、少しでも回答に自信がない問題にはチェックを付けて、再度見返していくぜ!と思って解いたら、半分以上の問題を見返すハメになりました。GCPの時の流れと同じですね……。

40分くらい時間が余ったかな?1時間以上はずっと問題と向き合っているので、集中力が切れないようにするのが大変でした。

提出して、その場で結果が表示されます。合格でした。
まぁ流石に落ちないだろうと思ってはいましたが、合否の瞬間はやっぱり緊張しますね。

後日届いたメールによると、スコアは881点(スコア範囲は100〜1000点)とのことでした。まぁまぁですね。

 

最後に

AWSはまだ、いままで業務で触っている期間がそこそこあったので、比較的少なめの勉強時間でSAAを取得できました。

次はGCPのProfessionalを狙ってみるかなぁ どうしようかなぁ。
もうちょい調べて考えてみたいと思います。

読んでいただいてありがとうございました!

GCPで意図しない課金を絶対に発生させないためには

こんばんは、mkurokiです。今年もあとわずかですね。

今日はGCPの小ネタです。

 

うっかり課金発生事案

GCP上でなにか環境を構築した後、使い終わって色々削除して
ヨシ!全部消したしこれで来月からは料金発生しないぞ!という状態のはずだったのに
翌月の請求を見ると、あれっ!なんかちょびっと請求が来てる!
ってこと、ありませんか?僕はありました。

よくあるのは、使い終わったVMは削除したんだけど、IPアドレスを消し忘れた!ってケースですかね。月10ドルくらい持っていかれて、悲しい気持ちになります。

また、2020 年 1 月 1 日から、無料枠に該当しない公開アドレスの VM インスタンスについても、追加料金が導入されるようです。

cloud.google.com上記によると、

についても、2020年1月1日から追加料金の対象となるようです。

まぁこれらについてはVMIPアドレスの削除をきっちりやっておけば、大丈夫かとは思いますが。とはいえ消し忘れやそれによる意図しない課金は避けたいですよね。

というわけで、意図しない課金を発生させないために最も確実な方法がコレです

 

プロジェクトを削除する

そうです、プロジェクトごとまるごと消してしまえば、それ以降の課金は確実に避けられます。

利用終了したプロジェクトは、必要なバックアップなどを取得したら、削除してしまい、無駄な課金が発生しないようにしましょう。0円GCP生活!無料!やったぜ!

特に企業などで使っている場合は、予算や費用負担の話などもあり、終了したはずのプロジェクトで費用の発生は避けたいですよね……。

 

そんなに迷うこともないかとは思いますが、実際の手順としては

左メニュー→IAMと管理→設定 から

f:id:mkuroki24sp:20191227175438p:plain

GCPプロジェクトの削除

「シャットダウン」をクリックして、プロジェクトIDを入力すると、プロジェクトの削除が始まります。

30日以内であれば、プロジェクトのオーナーは、削除を取り消すことができるようです

f:id:mkuroki24sp:20191227175650p:plain

削除の注意書き

「一部のリソースはこれより早く削除されることがあります」とのことですので、そこは(どこ?)注意が必要ですね。

 

まとめ

というわけで、GCPの意図しない課金を発生させないためには、プロジェクトの削除だよ!という話でした。

それではまた!