技術書典で出会った良書 カスタムコントローラ本はいいぞ
この記事は【推し祭り】技術書典で出会った良書 Advent Calendar 2019 7日目の記事です。
今回はバルゴさん執筆の『実践入門Kubernetes カスタムコントローラへの道』を推します!
本の内容
タイトル通り、Kubernetesのカスタムコントローラの解説本です。 自分は業務でKubernetesを使っていますが、 今年になって Kubernetes Custom ControllerやKubernetes Operator の話題を良く聞くようになったので正体を知るべくこの本を手に取りました。
以下目次から抜粋です。
- CRDとController
- client-goと知っておくべき周辺知識
- Sample Contorller解説
- controller-runtimeとcontroller-tools
- KubebuilderでSample Controllerを実装しよう
- OperatorSDKでSample Controllerを実装しよう
カスタムコントローラの説明だけでなく、 関連するKubernetesのController Loopの考え方、client-go / controller-runtime / controller-toolsといった関連する周辺知識、サンプルの実装まで非常に丁寧に書かれています。 カスタムコントローラについて日本語でここまで分かりやすくてステップ・バイ・ステップで学べる本は他にはないでしょう。 読了後はカスタムコントローラと向き合う自信がつきました :)
推しポイント
ここを推したいというポイントとして2つ挙げます。
カスタムコントローラ、CRD、CR、Operatorの違いを理解できる!
カスタムコントローラ周りの話題を追っていると、たびたび "CRD" や "Operator" といった単語が出てきます。 カスタムコントローラ関連の記事によってはこれらの単語をカスタムコントローラの同義語として書かれていますが、 それぞれの単語の意味するところと関係性が分かります。
一番最初の章に記載されていることなので、まずこの章を読むだけでも価値があります。
また、実装時にどのツールセットで上記のうちどれを操作するのかについても簡潔に書かれているのも推しポイントでしょう。
学べるカスタムコントローラの実装方法が1つだけじゃない! 比較しながら学べる!!
この本ではカスタムコントローラの実装方法として何と3つも学ぶことができます。1冊で3度美味しい!! 具体的には以下の実装方法を解説しています。
- 具体的には伝統的な実装方法 = The Kubernetes Way (既存のServiceやDeploymentといったリソースのコントローラと同じ実装方法)
- Kubernetes SIGs主導で開発されたフレームワーク Kubebuilder を使った実装方法
- CoreOS社発のOperator開発用のフレームワーク Operator SDK を使った実装方法
これが一番いい方法と決めつけずに実装方法を複数提示されているので、比較しながら自分に合ったカスタムコントローラの実装方法を見つけられるでしょう。 私はKuberbuilderによる実装方法が一番しっくりきました。
3つも解説されているのにも関わらず丁寧な解説のおかげで、手を動かしながら比較して使いやすいやり方を探せます。 題材は3手法とも同じカスタムコントローラ (Sample Controller)です。
書き手として1トピック解説する立場になって考えると、1つ実装方法を解説するだけでも大変なのに3つもとなるとめちゃくちゃハードルが高いです。 著者のKubernetes カスタムコントローラへの深い理解あってこそ書ける内容です。
どんな人に推せるか?
カスタムコントローラとはなんぞやを知りたい全ての人に推せます。 カスタムコントローラ / Operatorが流行りらしい or 凄いらしいで止まっていて手を動かしたことがない方は必見です。
以上、推し本記事でした。
IBM Cloud AppIDを使ってSPAに認証を組み込む
About
IBM Cloud アドベントカレンダー2019 1日目です!
このアドベントカレンダーのトップバッターということで、アプリ作成で最初に手をつける認証・認可にフォーカスしてSPA with AppIDを取りあげます。
今年の11月末にSPAでAppIDの認証を簡単に組み込めるようになったというアナウンスがありました。(以下記事参照)
上記のアナウンスは3行だけの簡素すぎる説明ですし、リンク先のドキュメントも英語のみであまり充実しているとは言えません。 このアドベントカレンダー記事は、SPAにAppIDを使った認証の組み込み実装例を提示します。
雰囲気だけ掴みたい人向けに、サンプルアプリを作りました↓
ログインするとQiitaの最新投稿表示するだけのやつです。 - サンプルアプリ (ユーザーは誰も登録していないので、投稿表示はできませんが...)
イメージとして以下のようなログインボタン、プロフィール表示ボタンを実装してみます。
この記事で説明しないこと
- OpenID Connect / OAuth2.0の説明 ... 別資料をご参照ください。個人的にはAuth屋さんのOAuth/OIDCシリーズがオススメです。
- ソースコードのAppID以外の実装・解説 ... AppIDに関係のある箇所しか解説しません。Angular CLIの説明は リファレンスをご参照ください。
何ができるようになったのか?
実装...の前に「え、今までSPAにAppIDの認証を組み込めなかったの?」と疑問に思われる方向けに補足します。
これまでもSPAにAppIDの認証を組み込むことはできていました。しかし、SPA "だけ" ではできなかったのです。 具体的には静的コンテンツを配信するバックエンドのWebアプリ(Node.jsで言えばExpressとか)を立ててバックエンド側にサーバーSDKを組み込むことで機能的に実現していました。
今回のアナウンスでは、新しく JavaScript Client SDK が登場しています。 このSDKにより バックエンドアプリ不要でSPA単体に AppIDの認証を組み込めるようになりました!!
SPAを動かす環境にバックエンドが必須ではなくなったため、SPAを開発するチームは静的Webサイトホスティングも使えるようになります。 (上記のサンプルアプリもNetlifyで動かしています)
実装例
ここからがこの記事の本題です。SPAのフレームワークとしてAngularを使って認証の組み込みを進めます。 事前にIBM Cloudのアカウント(FreeアカウントでOK)とAppIDインスタンスを作成しておいてください。
AppIDにアプリケーションを登録
SPAからAppIDに接続するために必要な資格情報を払い出します。
IBM CloudのAppID管理画面からアプリケーションタブを選択して「アプリケーションを追加」から登録しましょう。
AppID
タイプは必ず「単一ページ・アプリケーション(英語表示だとsinglepage application)」を選択してください。保存ボタンを押せば資格情報を取り出せます。
AppID Client SDKを利用してSPAを実装 (Service編)
まずはSDKをインストールしましょう。ドキュメント通りNPMでインストールします。
npm install ibmcloud-appid-js
次にAppIDとやり取りする部品を実装します。 認証のような他のコンポーネントでも共通で利用できる機能は、AngularのServiceとして切り出すと取り回しやすいです。さっそくAppID Client SDKを使ったAuthServiceを作成しましょう。
実装例は認証・認可のSaaSであるAuth0のSDK実装サンプルを参考にしています。
IBM Cloud AppID service in Angular
appId.signin()
でサインイン用のモーダル表示、 appId.getUserInfo(accessToken)
でAppIDで管理しているユーザープロフィールを取得します。
認証周りの実装はたったこれだけ!!
AppID Client SDKを利用してSPAを実装 (表示コンポーネント編)
続いてAuthServiceを使って認証画面の表示と認証ステータスの状態を取得してみましょう。
Using IBM Cloud AppID in Angular Components
HTMLのクリックイベントに onLoginPressed
関数を設定し、TypeScriptのコンポーネントにAppIDのサインインを呼び出す同名の関数を実装しています。
また、ログイン済みのみ isAuthenticated
に値が入るので表示の制御ができます。
AppIDにWebリダイレクトURLを設定する。
1つ前のステップまで完了した状態だと、ログインボタンを押してもモーダルに redirect_uri
が不正というメッセージが表示されます。
これはリクエストパラメータ redirect_uri
と同じ値がAppIDに設定されていないからです。
ここからがハマりポイントです。メッセージと一緒に書かれているドキュメントを辿ると {アプリURL}/appid_callback
を指定すれば良さそうに見えますが、2019/12/01現在はその限りではありません。
正解はモーダルのURLに埋め込まれた値を使います。 URLをエディタにコピペして、 redirect_uri
クエリパラメータの値をAppIDにセットしてあげましょう。
完成です🎉
これでAppIDの認証を組み込んだSPAの完成です。動かしてみましょう!
"Login with AppID" ボタンを押してモーダルにEmail / Password入力画面が表示されたらOKです。 モーダルに表示される画像やヘッダーの色はお好きなものをAppID管理画面から設定できます。
総括
ドキュメントは少ないですが、実装は数時間でできてしまいました。モーダル部品も用意されているので上記のように数十行あれば組み込めるのは簡単ですね。(Client SDK様様だ)
SPAでAppIDを利用したい方の参考になれば幸いです。
Appendix
参考資料
- AppID API Specification - https://jp-tok.appid.cloud.ibm.com/swagger-ui/#/
- IBM Cloud App ID Support for Single-Page Applications - https://www.ibm.com/cloud/blog/announcements/ibm-cloud-app-id-support-for-single-page-application
- IBM Cloud Docs AppID(Single-Page Applications) - https://cloud.ibm.com/docs/services/appid?topic=appid-single-page&locale=en
※ リンク切れの場合は、クエリパラメータに locale=en
をつけると通る場合があります。
JavaScript Client SDKの正体は?
JavaScript Client SDKの中身は、OAuth2.0のAuthorization Code Grant + PKCE のフローをAppIDのREST APIを叩いて実現しているライブラリです。
SDKなのでOIDC/OAuth2.0の仕組みを知らずとも容易に実装できますが、興味のある方はどのようなAPIを叩いているのかAppendixのSwagger定義を参照ください。
また、AppIDではSPAの認証認可方法としてWeb検索でよく出てくるOIDC/OAuth2.0のImplicit Grant Flowは 使えません 。
公式のドキュメントでも触れられていますが、Implicit Grant Flowには既知の脆弱性が指摘されています。
Swaggerの認可エンドポイント GET /oauth/v4/{tenantId}/authorization
にも フローの種別を表すリクエストパラメータ response_type
に token
(Implicit Grant Flow)が含まれないので意図的に塞いでいるものと筆者は推測しています。
以上。2日目以降のアドベントカレンダー楽しみ :)
Google Cloud Certified Professional Cloud Developer認定を取得しました
10月にタイトル通り認定に合格したので、振り返りです。 あまりProfessional Cloud Developer認定のことを書いている記事はググっても少ない気がするので、覚えているうちに書いておきます。 (Googleの認定なのにググっても情報が少ないとは...)
ちなみに今年の1月にもProfessional Data Engineer認定を取得してます。 そちらの記事もよければどうぞ。
どんな試験か?
公式サイトによると、Professional Cloud Developer認定をとると以下の能力を持つことを証明できます。
- フルマネージド サービスを利用する Google の各種ツールを使用して、Google の推奨する方法を実践しながら、スケーラブルで可用性の高いアプリケーションを構築します。
- また、次世代データベース、ランタイム環境、デベロッパー ツールを利用した経験もあります。
- 少なくとも 1 つの汎用プログラミング言語に精通しています。
- さらに、Stackdriver を使用するスキルがあり、コードのデバッグやトレースを行うための有意義な指標やログを生成できます。
ちなみに認定を取得すると証明書が発行されます。この証明書はCredential Holder Directoryというサイトで取得した人として全世界に自慢することができます。各国や資格ごとにどんな人が認定を取得しているのか見れるので面白いです。
また、取得すると認定ロゴ入りのパーカーやカバンを購入できるバウチャーコードも貰えます。(本当に貰っている人がいるのか謎でしたが、以前参加したイベントでロゴ入りカバンを持っている方がいました)
何を問われたか?
出題形式
制限時間2時間で全て四択問題です。ユースケースに沿って最適なプロダクト・ソリューション・実装方法を選択する問題が出題されます。
Data Engineerと比較すると、ユースケースのシチュエーションが具体的かつ踏み込んだ内容に感じられました。 また、試験ガイドに掲載されているケーススタディを題材にした問題が(体感で)3割程度とData Engineer認定試験よりも多めでした。
出題内容
試験ガイドに掲載されているように、以下の5つのトピックを織り交ぜた設問が出題されます。
- スケーラビリティ、可用性、信頼性に優れたクラウド ネイティブ アプリケーションの設計
- アプリケーションのビルドとテスト
- アプリケーションのデプロイ
- Google Cloud Platform サービスの統合
- アプリケーション パフォーマンス モニタリングの管理
例えば以下のような設問が出題されました。(あくまで例です)
(例1)
Google Compute Engineにのせたアプリケーションを公開するためにXXXX(gloudコマンドいくつか)の設定を以下のように行いました。しかし、インスタンスグループのヘルスチェックが通らず再起動を繰り返します。各インスタンスへのSSH接続が可能なことは確認済みです。この状況の原因と対応策を選択してください。
(例2)
あなたは同僚からCloud Datastoreからデータを取得するコードのレビューを依頼されました。以下のコード(JavaやPython)を確認してあなたがすべき助言はどれですか。
かなり具体的な設問ですね。逆にどのサービスが適切か選択させる問題はベストプラクティスさえ押さえておけば瞬殺できます。
認定を取得に向けた学習
ここからは事前に何を学習したか書き連ねます。期間的には約3ヶ月くらい見ておくと良いです。 基本的には他のProfessionalレベルの試験に合格していれば基本知識を流用できます。
- Coursera
- 認定をとるために必要な知識と実装レベルの取得は以下のコース(4つのサブモジュール)をやりました。
- 私が受講した時は英語版しかなかったのですが、ここ1~2ヶ月でGCPのコースは日本語版が増えているので、これから受講される方は日本語版のコースの選択をお勧めします。
- Data Engineerと被る領域が多いので、他の認定をお持ちの方はqwicklabだけでも良いです。
- qwicklab
- ハンズオン形式の学習サイト。
- 1テーマでも複数のトピックをまとめて学べる"Quest"をやると良いです(全てのQuestをこなすには¥3,00~¥4,000くらいかかりますが)。
- 自分は雰囲気でしか知らなかったStackdriverのQuestを一通りやりました。
- 模擬試験を受験する
- Google Forms形式で提供された無料の模擬試験を何度も受験することができます。
- 分からないことがなくなるまで解きます。
- 模擬試験の各問題は、例え正解していても「なぜ他の選択肢が誤りなのか」説明できるようになるまで調べると自信を持てます。
- 実際にGCPで手を動かす
- Data Engineer認定を取得した時と同様に、GCPの各サービスの知識はドキュメントと合わせて手を動かた時が一番身につきました。
- ここで重要な点として、 手が止まったら最初に読むべきは公式ドキュメントです。 マネージドサービスは結構な頻度でアップデートされるため、非推奨の機能を使わないようにするためにも公式ドキュメントを第1のリファレンスにすることをお勧めします。
- あとはひたすら手を動かしましょう!某メンターの言葉を借りるならば、"Just Do It!!" ですよ!
次はProfessional ArchitectもしくはNetwork Engineerを取りたいですね。
以上。
Kubernetes完全ガイド 読了後感想
『Kubernetes完全ガイド』を読んだので感想の投稿です。 先月の技術書典7でKubernetes関連の本を読んでKubernetes強者になりたい欲高まったので読んでみました。
ターゲット読者は誰か?
Kubernetesを利用する可能性のある方全てが対象となっています。 Kubernetesを何も知らない人は頭から中盤くらいまで読めば基本的なことは全部できそうです。(Dockerの説明は章が設けられているものの事前に押さえておいた方が良さそうですが...)
また、普段からKubernetesを使っている人でも復習と新しい発見ができる本です。リファレンス用途としても良さそうですね。
どんな本か?
この本の『はじめに』で記載されているように、 Kubernetes上のアプリケーション開発で利用する可能性のあることを網羅的に解説されています。
内容としては前半〜中盤過ぎまでは、Kubernetesそのものの解説と、アプリケーション開発者が押さえておくべきリソースの解説がメインです。 リソースも5つのグループに分けて体系的に説明されており、リファレンスとして後で読んでも分かりやすい構成になっています。
また、後半からはKubernetesのリソースの他にもアプリケーション開発で忘れてはならない セキュリティやモニタリング、ロギング、CICD、サービスメッシュといったトピックにも触れられています。
ピックアップ
個人的にこの本のすごいなと思った点を2つピックアップします。
体系的にリソースが解説されている
各リソースを関係性を理解した上で丁寧に解説されています。
もちろん1つ1つのリソースの説明はQiitaやブログ記事をググればなんとなく理解することは可能です。 ですが、例えば以下のようなリソース違いやkubectlコマンドの意味、リソースの必要性を説明せよと言われると途端に難しく感じられます。
- DeploymentとReplicaset
- PersistenceVolumeとPersistenceVolumeClaim
- ConfigMapとSecret
- Podのrequestとlimits
- ClusterRoleとClusterRoleBinding
上記のリソースは触れる機会が多いのにも関わらず意味を理解し切れていない、いわゆる『雰囲気』で触りがちです。 2つずつリソースを並べましたが、これらの違いやkubectlのコマンドの意味を説明できなかったら断片的でも読む価値があります。
隠れた標準機能を発見できる
また私は初見でしたがKubernetesの標準機能でここまでできるのかと目に鱗な機能を知ることができます。 一例として以下のようなリソースの解説がされていました。
- リソースに制約を設けるリソース (ResourceQuota, LimitRange, PodPreset)
- セキュリティに関するリソース (PodSecurityPolicy)
- ネットワークに関するリソース (NetworkPolicy)
- 外部サービス(AWSやGCP)を作成・管理するリソース (ClusterServiceBroker, ClusterServiceClass, ClusterServicePlan)
上記の機能は、アプリ開発者よりもKubernetesクラスタを運用を担当する方やシステム全体をマネージするSREの方々が意識することが多いかもしれません。 それでも自前で実装したり難しいツールを入れなくともKubernetesが標準的に提供している機能でリソース制約や外部サービスのプロビジョニングまでできるのは驚きです。
この本が執筆されたのはKubernetes v1.11なので、最新版(1.16)だともっと増えているかもしれません。。。
総評
読んでみて改めてKubernetesの奥深さを理解できました。まさに完全ガイドとの名前の通りの書籍です。
私は業務でもKubernetesを使っていますが、 今まで知らなかったことや雰囲気で分かったつもりになっていたことをキャッチアップすることができたので超絶推せる本です。 (弊社の同僚にもオススメしておきました。)
この書籍で扱われていないこともまだまだあるとの情報を得ましたので、深掘りしていくのが楽しみです。
『Kubernetes完全ガイド』読了🙏
— ぽんず (@ponzmild) October 17, 2019
今まで雰囲気で使っていた各リソースの使い方を理解できるし、知らないリソースもあって新鮮でした。
また、Kubernetesを支えるエコシステムのツールやプロジェクトにも触れられる。まさに完全ガイド。
リファレンスとして読み返せるように手元に置きたい一冊!
せっかく本を一読したのでステップアップのために 2019年度内にCKAD取得を目指します。 さて、頑張るぞ。
技術書典7 参加レポート ~アウトプットは出す方も見る方も楽しい~
9/22開催の技術書典7に出展者として参加してきました。今回はサークル参加者として、また1人のイベント参加者としての振り返り記事です。
実は技術書典には初参加でもあります。ツイッターで盛り上がっているのを見て、これは自分もやってみていいんじゃないかと勢いで申し込みました。
勢いで申し込んだものの、結果としては参加者で行くよりも収穫があったと感じます。
どんな本出したの?
分散システム間のメッセージングのためのOSSである、NATSの本です。 NATSはシンプルかつスケーラブル、ハイパフォーマンスなメッセージをPub/Subパターンでやりとりするためのプロダクトです。 Boothで電子版書籍版を出しているので、ご興味ある方は是非読んでいただければと。
この本を出すためにNATSを理解しようと悪戦苦闘しましたが、苦痛ではなかったです。
Slackグループに参加してリアルタイムで動向を追ったり、GitHubでソースコードを読み解いたり、
最後には自分でクライアントアプリ作ったりしてました。
NATSへの理解がだいぶ深まった自信があります。
売り上げ結果
リアルな数字としてどんなものか参考までにお見せします。
- 最終被チェック数: 106
- 印刷: 物理本80部 + DLカード150枚
- 売上: 物理本57冊 + DLカード58枚 (基本は物理本とセットだが、単品販売が1枚あった)
- 現金: 簡単後払い = 27 : 31
新刊の進捗や入稿といった様々なタイミングでTwitterで宣伝したおかげか、被チェック数は初参加ながらいい伸びでした。
支払い形態に関しては、予想よりは現金払いが少なかったです。 イベント2日前に公開されたiOS13で技術書典アプリが動かない事象があったので、もっと現金払いが多いかなと想定してました。 (私は当日はiOS12が入ってるiPadを持って行きました)
上記以外にもBoothでも数点購入されている方もいらっしゃたので、実質的には計60冊以上売れたことになります。
これだけ多くの方に興味を持っていただけたことに感謝いたします。 購入していただいた皆様、また購入せずともスペースまでお立ち寄り頂いた皆様、本当にありがとうございます。 在庫は次回のイベントに参加した時に持ち込む予定です。
当日の様子
まず最初に感じたのは、 ワンオペは無理ですね!!!!(確信)
後輩が売り子として1人ヘルプ(しかもコミケで何度か売り子経験あり)してくれたことが大きくプラスに働いて、
慌てず落ち着いてオペレーション回せました。後輩が来なければ本を買いに行く余裕はなかったと思います。
本を頒布している間は予想以上に割と話しかけてくださる方が多かったです。
商業誌を書かれている方もスペースに来ていただいたのでビックリしましたが、
お話しできた上に新刊を買っていただいたのでめちゃくちゃ嬉しかったです。
それにお隣のスペースの方(Prometheus本の方)ともお話しもできましたし、 実は今回の新刊の中でNATSをPrometheusで監視しようという章があったのでそれで話が盛り上がりました。 (もちろん両隣のスペースの新刊は紙本買いましたよ)
反省点
ここまでは良かったことを書き連ねましたが、反省点もいくつかありました。
当日にブースでいくつか質問をいただいたのですが、自分の中で整理しきれていないことがいくつもありました。
事例と比較という割と基本的なことが疎かになっていました。
印象に残っている質問は以下4つですね。これらは整理してブログでアウトプットしようと思います。
- NATSとMQTTの違いは? (Kafkaとの違いを聞かれるかと全くなかった)
- ぶっちゃけAmazon SNSとSQS使えばよくない?
- NATSは他のメッセージングプロダクトを置き換え得る?
- NATSを使った事例ある? (Cloud FoundryとNGS以外は?)
イベント参加者として
サークル参加者ではなく、1人のイベント参加者としての感想。
他のサークルスペースの本も楽しみにしていたので、買いあさりました。 興味のあるもの、技術的性癖に刺さるものばかりで、Boothで買ったものを合わせて全26冊購入です!
どのブースのどの本を買ったか並べてみましたが、この記事を買いている途中で買い忘れた本を思い出したのでまた増えるかも笑
だいぶ多くない?笑 pic.twitter.com/bWJaGuqXHd
— PonzMild / 技術書典7 NATS本 (@ponzmild) 2019年9月22日
ちなみに私が買った本は全て簡単後払いかBooth購入可能でした。
技術書典アプリは結構使いやすかったですし、当日大きい財布も持たなくて良かったのは助かりましたね。
(コミケだと硬貨とお札を大量に用意しないといけないので、コミケに比べれば気楽)
技術書典7は総じて楽しい時間でした! 別の技術書イベントにも出展したいですね。
今回のNATS本をNATS Streamingも含めてパワーアップさせたいですし、KafkaとMQTTとの比較本もいいですね。
最近はサービスメッシュ周り(Istio, Envoy, Gloo, Openshift Service Mesh)も気になってます。
アプリよりも少し下のレイヤーに興味が出てきているので、ネタを集めて温めておきます。
最後にこの本をレビューいただいた @hiroga_cc さん、読者目線でのレビューいただき本当にありがとうございます。
以上。
Pythonによる新しいデータ分析の教科書 読了後感想
今回は自分にしては珍しいPythonの読書記事です。
データ分析と機械学習を使った予測モデル構築のお仕事をすることになり、 基礎練習として翔泳社から出版されている『Pythonによる新しいデータ分析の教科書』を読んだのでその感想になります。
Pythonによるあたらしいデータ分析の教科書 (AI&TECHNOLOGY)
- 作者: 寺田学,辻真吾,鈴木たかのり,福島真太朗
- 出版社/メーカー: 翔泳社
- 発売日: 2018/09/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
ターゲット読者は誰か
この本でターゲットにしているのは、主に以下2点が当てはまる エンジニア です。
- Pythonをある程度理解している
- データ分析・予測モデルの作成を行いたい初学者〜中級者
「プログラミングは全くできないけど、Pythonを使えば簡単にできるかも」と安易に考えている方には向いていないです。 実行環境としてJupyter Notebookを使いながら、Pythonでガッツリとコーディングします。
何が書かれていたか
これからデータ分析・機械学習を行うエンジニアに向けて、以下4つのテーマが書かれています。
- エンジニアが求められている役割
- 分析に使う数学の基本
- ライブラリを使った分析・可視化・予測モデル構築
- データ収集と、自然言語・画像処理のためのデータ加工
内容的には学術的な部分には深入りせずに、機械学習を使った分析の各ステップに重点を置いています。 そのため、実務的にエンジニアが使うライブラリ・前処理・モデルの知識にページ数が割かれていて、Pythonや機械学習そのものの説明はサラッと流しています。
また、機械学習の処理の手順に沿って、データの加工→可視化→モデルの構築→評価の順に章立てされているため それぞれでどのような処理が必要になるのか、手が掛かる部分はどこか、クラウドサービスを使いながらできるところはどこかと想像しながら学べます。大きな流れの中の立ち位置が明確なので、闇雲に手を動かしているという感じがしません。これはいいぞ!
章立てとともにこの本で重要なのが機械学習の手順として以下の図です。 本書10ページに掲載されているこの図は紹介されているライブラリ以外でも共通して覚えておくべきものです。
クラウドベンダーの提供するサービスを使うと多くの手順が省略・簡略化される傾向にありますが、自分が今どの処理に手をつけているのか、次はどの処理に進むのかを理解する助けになりますね。 機械学習の記事や用語を調べるとそれぞれのステップが個別に紹介されることが多いので、この図を見てようやく全体像を掴むことができました。
ライブラリの章では以下のものが紹介されています。どれも分析時に頻出するライブラリです。
- データ加工
- NumPy
- Pandas(データ加工)
- データ可視化
- Matplotlib
- モデル構築と評価
- scikit-learn
それぞれ手を動かしながら学べるところも、理解しやすいポイントです。1章の中でそれぞれ30~40ページほどの内容なのでとっつきやすいです。 データもアヤメの有名なデータセット(Iris dataset)を使って進めていたので、個人的には楽しかった。
さらに、ここで作成したモデルはpickle形式やjoblib形式でエクスポートすればクラウドベンダーのサービスで利用することもできます。 GCPだとAI Platformでscikit-learnのモデルをトレーニング・デプロイできるので、クラウドと機械学習を一緒に使う方法を学ぶこともできますね。
総じて読みやすい。全体像から詳細を順序立てて進めて理解できる良書だったと感じました。
参考
機械学習そのものの説明はサラッと流されているので、GoogleがUdemyで配信している『はじめてのAI』を視聴することをオススメします。
https://www.udemy.com/google-jp-ai/
自分自身は予測モデル構築や機械学習には一切興味が出なかった人だったので、実務的にはどんなケースがあるのか、エンジニアとしてどのように解決するのかを学ぶのには良い入り口だったと思います。
メッセージング基盤のNATSを超ざっくり解説する
システム間を疎結合に保ちつつ非同期で通信しようとすると、必然的にメッセージング基盤が必要になります。
もしメッセージング基盤を手っ取り早く使うのであれば、クラウドベンダーのサービス、例えばAmazon SNSやGoogle Cloud Pub/Subを使うのが一番です。(自分で環境を立てなくて済むならその方法を選択した方がいいというのが自論です)
ただし、手元に環境を用意したり接続用のロールやサービスアカウントを作るのは面倒です。
OSSはどうでしょうか?メッセージングやストリーミング処理のデファクトスタンダードとなっているKafkaという素晴らしいプロダクトがあります。
ただし、耐障害性もありスケーラビリティを実現するためにZookeeperの複雑性を受け入れなければいけないので、これまた面倒臭いです。(もちろん、Amazon MSKやConfluent Cloudのようなマネージドサービスを使う手もあります)
では、もっと簡単にPub/Subスタイルのメッセージングを自前で用意できないのかと探して見つけたのがNATSでした。
詳しいところは技術書典7に出す同人誌で書こうと思いますが、 NATSは何が特徴で何が他よりもすごいのか、頭の整理のためにもブログ記事として書き記しておきます。
Subject-based messaging
メッセージのやりとりは全てSubjectを通じて行います。
KafkaやAmazon SNSのようなPub/Sub型のメッセージングに慣れた方はメッセージの購読にTopicやSubscriptionを作成したでしょう。 驚くことにNATSには TopicやSubscriptionがありません 。PublisherとSubscriberの間に立つ登場人物は Subjectただ1つです 。
PublisherはSubjectを指定してメッセージを配信し、同じSubjectを購読しているSubscriberにNATSがメッセージをルーティングしてくれるのです。 「NATSは(メッセージ)キューではなくルータ」であると主張している方もいます。
Flexible Subject
全てのメッセージのやりとりはSubjectを通じて行うと書きましたが、配信先は1つに限定されません。 Subjectにはワイルドカードを使えます。
ワイルドカードにも2種類あり、特定の1階層のみ全てのメッセージを受け取る *
(アスタリスク)と、特定の階層以下全て階層向けのメッセージを受け取る >
(不等号) があります。
例えば、time.*
というSubjectを購読するSubscriberは、Publisherが time.us
と time.jp
に向けて配信したメッセージのどちらからも受け取れます。ただし、time.jp.tokyo
のようなさらに下の階層までSubjectが指定されてメッセージが配信され場合はSubscriberはメッセージを受け取れません。
time.>
というもう1つのワイルドカードを使ったSubjectならば受け取ることができます。
Kafkaに慣れた方ならば、1Topicに対して複数のSubscriptionがぶら下がり、これらのSubscription全てをSubscribeしている状態をイメージしていただくと良いです。
3style messaging
メッセージングのスタイルにも3種類あります。
- Pub/Sub
- Request/Reply
- Queue Group
Pub/Subを拡張してメッセージの返信(Request/Reply)もできることが特徴です。 AWSだと最近Temporary Queueというものができましたが、やっていることはこれと近いですね。
また、Queue Groupのようなロードバランサーの仕組みがあるのも特徴ですね。
Zero Configuration
設定なしにメッセージングを始められるのも特徴です。 例えば以下のようなことを実現するのに設定は全く不要です。サーバーやクライアントを構成したら自動的に設定されます。
- Subjectにメッセージを配信するための設定
- Subjectをからメッセージを購読するための設定
- SubjectからSubscriberへのメッセージ配信のロードバランシングの設定
- 災害対策のためのNATSサーバークラスタの冗長化
Simple Client
クライアントも実装が楽チンです。クライアントライブラリ自体が30以上の言語の実装があり、インターフェイスもシンプルであるためです。
Node.jsのクライアントライブラリである nats.js
を例にとると、以下のようにしてメッセージの配信・購読が可能になります。
全てのメッセージがSubjectを通じてやりとりされるため、クライアント側も実装が簡単です。見た目もスッキリしていますね。
Deliver AT MOST ONCE
NATSはメッセージを1回しか配信しません。(At Most Once戦略)
これはディスクやDBのような2次ストレージにメッセージを保存していないためです。 裏を返すとメッセージを管理する手間が省けるのでシンプルではあると言えます。(物は言いようですね) この特性のため、受け取りに失敗した or 購読する前に配信されたメッセージを再送する手段がありません。
その一方でKafkaは稼働しているマシンのディスクにメッセージを書き込んでいるため、始点を指定してメッセージを再送できます。
また、ストリーミング処理のための拡張実装であるNATS StreamingやLiftbridgeはこの問題を解決して最低1回(At least once)配信できるようになります。
もう少し深掘りしたことや本番運用に向けたNATSのクラスタリング・認証認可の話は技術書典7で出す本をお楽しみに!!