2018-03-12
コンテナを管理するオーケーストレータとしてデファクトスタンダードになりつつあるKubernetesに関する入門書『入門Kubernetes 』を翻訳しました。2018年3月22日に、オライリー・ジャパンから発売されます。原著は『Kubernetes: Up and Running 』です。
Kubernetesの開発者たちが直接Kubernetesを解説した本で、Kubernetesでアプリケーションを動かすために必要な色々な概念を、実際にKubernetesクラスタ上で動かしてみながら学んでいくという構成になっています。
また、チュートリアルだけでなく「なぜコンテナを使うべきなのか」「どういう経緯でKubernetesが生まれたのか」「マイクロサービスの何がいいのか」といった、コンテナやマイクロサービスが広まって来た背景についても書かれています。そのため、コンテナはほとんど触ったことがないという人でも読み始められるようになっています。
入門書なのでKubernetesの機能のすべてが網羅されているわけではありませんが、Kubernetesを理解するための基本的な事項については一通り書かれています。Kubernetesの公式ドキュメントはとても丁寧に書かれているので(ただし英語)、まずこの『入門Kubernetes』を読んでKubernetesの仕組みと基本的なリソースを学び、さらにその先を知りたい場合には公式ドキュメントを読み込んでいくというのにぴったりだと思います。
日本語版独自の改善点
原著はKubernetes 1.5あるいは1.6をベースに書かれています。日本語版には、翻訳完了時の最新版であるKubernetes 1.9までに加えられた変更などを、注釈などの形でできるだけ反映しました。チュートリアルを簡単に進められるように、原著の内容に合わせてサンプルデータのリポジトリ が用意されているのですが、これも日本語版に合わせてKubernetes 1.9対応データを含むリポジトリ を用意しました。
また、原著への「内容はいいのに誤植が多すぎる」といった指摘に対しては、翻訳の際にできる限り修正を反映させるようにしています。
翻訳の経緯と謝辞
英語を日本語に翻訳することで日本語の情報量を増やしたいという思いで、人力翻訳コミュニティYakst というサイトを作って翻訳したり、『SQLパフォーマンス詳解』というデータベースに関する本の翻訳 などをしてきました。その先に、いつかは書店で売られる本の翻訳がしたいと思っていたところ、機会をいただいて実現することになりました。
私自身Kubernetesに関してはまだまだ経験が浅いこともあり、Kubernetesの運用経験豊富なレビュアのみなさまからの指摘無しにこの本は完成しなかったといっても過言ではありません。レビューしていただいた@mahataさん 、@Ladicleさん 、@superbrothersさん 、@strskさん 、@deeeetさん (順不同)には本当に感謝するばかりです。
「私は『入門Kubernetes』でKubernetesを始めました」という人がたくさん現れて、日本のKubernetesコミュニティがさらに盛り上がっていくことにつながれば、翻訳者としてこの上ない喜びです。みなさんぜひ読んでみてください！
2017-02-12
The English version is at the end of this post.
2月10(金)に開催されたTokyo Rubyist Meetup というイベントで、自分が翻訳したSQLパフォーマンス詳解 という本をベースにして「How indexes work in relational databases」という題で発表した。題名からわかるように、英語での発表。
Tokyo Rubyist Meetup は、Doorkeeperの社長Paul McMahon さんが主催している、Rubyのことを中心にしつつも色々なトピックを取り上げている英語話者向けの勉強会。Paulさんからお声がけがあって、DBエンジニアからの知見はRubyistにもうけると思うよということで、英語の勉強と本の宣伝とデータベース知識の整理の意味で発表することにした。Paulさん貴重な機会をくれて本当にありがとうございました！
内容的には、SQLパフォーマンス詳解 (の英語版 )の第1章の要約みたいな感じで、インデックスがなぜ必要なのか、Bツリーインデックスはどうやってデータを探すのに役立つのかといった基本的なところを書いた。Active Recordばっかり使ってて、SQLがどう動いているのかあまり意識していなかったり、高速に応答するクエリをどう書いたらいいのかわからない人に向けて、インデックスコワクナイヨ、ということを言ったつもり。しかし特定のDB(MySQLとかPostgreSQLとか)についてあえて触れなかったので、内容的に抽象的すぎたかもしれない。こういう発表って、どの程度の人をターゲットにするかブレないようにすること、そして抽象的すぎず突っ込みすぎずな内容にもっていくのが難しい。
今年は意識的に英語でアウトプットしていこうと思っているので、できる限り機会を見つけてこういう場で発表するつもり。
I gave a talk “How indexes work in relational databases” based on the book SQL Performance Explained at Tokyo Rubyist Meetup held on Feb. 10 .
(See the material above.)
Tokyo Rubyist Meetup is a tech meetup for English speaking Ruby engineers organized by the CEO of Doorkeeper Inc. Paul McMahon . One day, he gave me an email and suggested me to talk about a topic related to databases. I decided to talk something to practice my English, to promote the book, and to reorganize my thought on databases. Thank you very much Paul, this was my precious experience!
The talk was basically the summary of the chapter one of SQL Performance Explained , including basic topics like why indexes are needed and how B-tree indexes search a record. The talk was for developers who use Active Record and don’t have enough knowledge about indexes and what I wanted to say for them is that don’t be afraid of indexes. I intentionally avoid to write about a specific database management system (MySQL, PostgreSQL, etc.) to focus on how indexes work in general but because of that, the talk might be too abstract. Hopefully, the talk was a good introduction to the internal of databases for attendees.
I’m going to talk at some more events in this year to improve my English skill.
2016-10-24
Twitterボットを作るのが趣味という記事 を以前書いたが、そのからみでAWS(Amazon Web Service)、GCP(Google Cloud Platform)、Microsoft Azureの主要3クラウドの障害情報Twitterボットを作った。面白いもので3サービスとも障害情報の提供方法やポリシーが違っていて、ボットのような障害情報を取ってきて通知する仕組みをつくるのはちょっと面倒。せっかくなのでボットの宣伝も兼ねて障害報告に関するサービス間の違いを挙げておく。自分で通知の仕組みを作ったり、サービスを選ぶときの参考に。
ちなみに、これらのサービスを既に使っている人は、単純にこれらのボットをフォローするか、Slack(英語の公式ドキュメント 、日本語記事 )やHipchat(Zapierを使った方法の日本語記事 )などにボットのツイートを通知するようにしておくと、障害検知の一環としても使えますのでぜひどうぞ。どのボットも障害発生時間などを日本時間に置き換えてツイートする仕組みです。
AWS
障害情報サイト
http://status.aws.amazon.com/ 大まかな地域ごとにタブが並んでおり、その中に地域内の全リージョン、全サービスが一列に並ぶ
障害があると左端の緑の丸がオレンジになり、障害の詳細がDetails列に簡潔に書かれる
他のサービスと比べると障害内容の記述はシンプルであまり詳細は書かれない
過去の障害履歴は下半分に1週間分(それ以前にもさかのぼれる)表示されるが、サービス数が多すぎてやや見にくい
比較的定型的な表現が多い
タイムゾーンはPST/PDT
機械的に障害情報を取る方法
全リージョンの全サービスの情報がそれぞれ1つずつRSSフィードで提供される
その他に全障害情報が含まれるRSSフィード もある
基本的には上記サイトに表示される内容がフィードにも書かれる
所感
いいところ
リージョン及びサービスごとにフィードがあるので特定サービスごとに監視したい時は楽
定型的な表現が多いので訳したり表現を拾って処理を分岐したりしやすい
悪いところ
過去の障害情報が見にくいので他サービスのように時系列の一覧などが欲しい
フィードの数が多すぎる(all.rssをうまく使えばいいが)
他サービスと比べて障害情報の詳細さが足りない
GCP
全リージョン対象 @gcpstatusjp
日本リージョンはまだない(開設予定 )
現状、障害がリージョンごとにうまく分けて通知されないので日本リージョンができても別ボットにしづらそう
障害情報サイト
機械的に障害情報を取る方法
サイトに掲載されている詳細情報や障害のレベル(Severity)、開始・収束時刻なども載ったJSONと、少し情報が少ないRSSの2つ
所感
いいところ
フィードの他に詳しい情報を含むJSONフィード が提供されている。しかもちゃんとスキーマ情報 も別にある
Severityと障害の開始・収束時間があるのが非常にいい
悪いところ
リージョンが障害情報の詳細にしか書かれないので、特定リージョンの障害のみを検出したりするのが困難
Azure
障害情報サイト
機械的に障害情報を取る方法
全リージョンの全サービスの情報が含まれるRSSフィードが1つのみ
障害内容の記述はサイトに表示されるものと同じだが、Severityなどの情報は含まれない
所感
いいところ
悪いところ
RSSフィードのスキーマが微妙(リージョンとサービスが同じCategoryに列挙されている)
障害がない時はRSSフィードの内容が空になる
どんな情報がどのように配信されるか分からない
障害が終わった時の情報がフィードから得られない
他サービスだと、障害収束後に「こんなのありました」という報告パターンがあるがそういうのをどう出すのか謎
サイト上には表示されるがRSSフィードに載らない情報が多い
全体的に
利用者から見てもっとも丁寧な感じなのはAzureだが、フィードがいけてないので情報の加工は一番やりにくい
AWSは情報の詳細さが他サービスと比べて全然足りない
障害情報を加工して通知などに使いたい時には圧倒的にGCP。Severityや障害開始・収束時間など詳しい情報をパースしやすい形式で提供しているのはGCPのみ
