あるアカウントで運用しているドメインを別のアカウントに遷移したので、 未来の自分がまた同じ事をする際に思考を再現できるようにするまとめました。 前提条件 ドメイン(domain)をAWSのアカウントAのRoute 53で管理(domain.com) domainのサブドメインsubもアカウントAのRoute53で管理(sub.domain.com) subはEKS上でAWS Load Balancer Controllerとexternal-dnsを利用して設定している ALBを立ち上げてAレコードを登録するのが自動で行われる subsub.sub.domain.comなどを作る可能性もある subはACMで証明書を作成しており、DNSでの検証をしている subのEKSやRDSを可能な限りアカウントBに移動したい 理由がって残すのは(金額が高くないなら)OK この前提条件のもとで、sub.

「ユニコーン企業のひみつ」という本を読みました。 一見すると書かれていることはひみつという程ではなく、言われると知っているというものばかりですが、 Spotifyはそれを想像を超えるレベルで徹底していて、このやりきる事こそがひみつにあたるのではという感想を持ちました。 例えば本書では「スタートアップは学習する機械」「素早く失敗して学習をする」「ミッションを定義して方向性を示す」「チームに権限をもたせ信頼する」といった、 ある程度ベンチャーの風土に親しんでいれば知っているようなトピックが多数挙げられています。 そのため一見するとそこまで新しいことはなさそうに見えるのですが、実行される内容は生半可ではありませんでした。 例えば決定権をチームに持たせて自走させるといったようなことが語られますが、上位レイヤーは必要な情報を提供したりミッションを伝えるが決定はしないという役割に徹しており、チームに与

最近、「煽動者 ～徹底プロモーション 仕掛人の哲学～」という本を読みました。 これは今かなり勢いのあるアニメ・ゲームのメディア企業であるブシロードの代表取締役会長の自伝的な本です。 2013年1月出版なのでラブライブ！(同時期にアニメ開始)やBanG Dream!(2015年)がブレイクする前の話で、主にヴァイスシュヴァルツとヴァンガード、新日本プロレスについて書いています。 とはいえコンテンツ制作的な部分にはあまり触れておらず、社長の自伝とどういう戦略でやったのかとか、マーケティング手法とかがメインです。 この本で面白いのはヴァンガードの頃にやっていた広告戦略をBanG Dream!（以下バンドリ）の時や現在でも踏襲しており、かつなかなか他に同じようなことをしているコンテンツ会社がいない手法だなというところです。 その手法というのは大きく分けて以下の2つです。 徹底した再放送 常にリアル

9/12から始まるる技術書典9で「OpenAPI 3を完全に理解できる本 3.0.3対応版」を頒布します。 OpenAPI3に関するおそらく唯一の日本語完全解説本です。 この本ではOpenAPI 3の説明や、実際にどういう風に定義を書いていくかについての説明、および簡単な応用例などを載せています。 こちらは、「技術書典７でOpenAPI 3の完全解説本を出しました」で頒布したものをアップデートし、現在の最新である3.0.3に対応させたものです。 差分はそれほど大きくないため、既に持っている方向けには電子版を最新版に差し替えています。 再度DLしていただくと最新のものに差し替わります。 また、物理本を少量ですが用意しました。 他にも kubectl完全逆引きリファレンスと Microservices architecture よろず本 その三は物理本を若干数用意しています。 Microser

まとめ タスクランナーをどうするかは人類共通の課題 自分以外のコンテキストの違う人を考えると大変 フロント・スマホの人がサーバ触るとか 汎用的に使えるツールは表現力や変更が辛い make, シェルスクリプト, 自作バイナリ 表現力が高いツールは環境設定でハマりやすい node/ruby/pythonは手元に入ってない場合がある バージョン・依存関係問題で失敗したりする Dockerで開発環境を提供してもDockerの外の事柄には対応できない Dockerビルドしてデプロイとか cargo-makeがいい感じに使えそう バイナリ一個置くだけでインストールできる rustのツールであるcargoは不要 Makefile.tomlの表現力がそこそこ高い Pythonで拡張可能 npm-scriptsのより汎用的に使えるイメージ 欠点も少ない 表現力は豊か Dockerと組み合わせばだいたいなんと

技術書典　応援祭で頒布した「kubectl完全逆引きリファレンス」が加筆修正を加えて技術の泉シリーズから出ました。 主な内容は「技術書典 応援祭でkubectl完全逆引きリファレンスを頒布します」の通りで、 kubectlの一通りのコマンドについて説明をしています。 さらに、前回の頒布後にリリースされた最新のkubectl 1.18に対応しており、deprecatedや削除されたコマンドに対応しているため、よりおすすめの一冊になっています。 (同人誌版は1.17対応) 目次やサンプル 【目次】 第1章　はじめに 第2章　kubectlの基本 第3章　リソースを操作する 第4章　定義ファイルに関するコマンド 第5章　Podやコンテナを操作する 第6章　複数のPodを作るリソースに対するコマンド 第7章　ロールアウトに関するコマンド（rollout） 第8章　スケールイン・スケールアウトに関す

まとめ 秘密情報をEKS上で楽に管理したい。 これまでは秘密情報を暗号化したファイルを使って注入してた 変数ごとに何が変更されたかを確認するのが面倒 AWS KMSで暗号化してたのでAWS CLIのインストールのためにPythonを入れるのが微妙 KubernetesのSecretをそのまま使うのは避けたい Base64してるだけで暗号化してない k8sの権限の強い人からは見えてしまう 環境変数の値だけを暗号化してPod内で複合 リポジトリに読める形でコミットできる 追加・変更されたか否かのレベルでなら確認できる Pod以外は複合できないためマルチテナントなk8sだと権限管理が楽 shushならバイナリ一個入れるだけですむ GKEに移っても実装できそうな規模なのでなんとかなりそう。 欠点もある バイナリを一個置く必要がある entrypoint/commandの変更が必須 起動時に暗号化し

3/7から始まっている技術書典　応援祭で「kubectl完全逆引きリファレンス」を頒布していました。 技術書典 応援祭でkubectl完全逆引きリファレンスを頒布します 4/5で終了したので、新刊の販売冊数と集計結果をまとめてみました。 なお、紙＋電子はとらのあなでも販売しています。 https://ec.toranoana.jp/tora_r/ec/item/040030816901/ 電子版のみはBOOTHでも販売中です。 https://ota42y.booth.pm/items/1854936 まとめ 定期的にポツポツ売れている 送料がかかっても電子＋紙のほうを求める傾向がありそう 技術書典公式の物理本特集も効果が出てそう 最後の追い込みがある 実際の即売会だと無いのでネット特有の減少 集計方法 前回の「#技術書典 応援祭の集計スクリプトと中間集計」と同じスクリプトを使って集計しま

3/7から始まっている技術書典　応援祭で「kubectl完全逆引きリファレンス」を頒布しています。 技術書典 応援祭でkubectl完全逆引きリファレンスを頒布します 3/21で開催からちょうど二週間たったので、新刊の販売冊数と集計結果をまとめてみました。 まとめ 定期的にポツポツ売れている 送料がかかっても電子＋紙のほうを求める傾向がありそう 技術書典公式の物理本特集も効果が出てそう ただしデータが少ない(26件) 集計方法 以下のスクリプトを使いました。 サークルの販売履歴ページに移動 3/7以前のデータが出るまで「もっと読む」を押す デベロッパーコンソールから以下のスクリプトを実行 出力されたcsvを集計する 日付、種類、本の名前、価格　の４データになります 集計結果 売上がなかった日もあるため棒がないのは正常です。 考察 電子版は初日にピークを迎え、後はゆっくりと買われています。

3/7のから始まる技術書典　応援祭で 「kubectl完全逆引きリファレンス」を頒布します。 https://techbookfest.org/product/5767351924424704 kubectlの様々なコマンドを、実際にやりたいことから逆引きが出来る本です。 Kubernetesを始める際、運用していく際に手元に置いておく事で安心の一冊になっています1。 Podの操作はもちろんのこと、スケールアップ・ダウンしたいときやクラスターの外部に公開する場合、Nodeを停止したい場合など様々な利用シーンから、対応するkubectlコマンドの逆引きができるようになりました。 形式は紙＋電子で、とらのあなでも販売しています。 https://ec.toranoana.jp/tora_r/ec/item/040030816901/ 電子版のみはBOOTHでも販売中です。 https://ot

2019年の振り返りと2020年の話。 2019年の振り返り 2019年は簡単にまとめるなら技術の幅を広げた1年でした。 ちょうど7月で転職したので一年を転職前後に分けられるので、それぞれ振り返ります。 転職前 株式会社FiNC Technologiesを退職しますでも書いたように、1月から6月まで仕事をしていました。 とはいえ、Ruby on Railsエンジニアとしての活動はほぼ1月しかしておらず、だいたいの期間をSageMakerやAWS Glue等を利用したシステム開発をおこなっていました。 また、この期間には以下のような対外的な活動もしていました。 特にRubyKaigi直前まではJAWS DAYS+RailsDM+技術書典本+寄稿+転職活動が重なってかなり大変でした。 このうち、JAWS DAYS、RailsDM、RubyKaigiに関しては会社の業務として取り組めたので、許可

Bonfire Backend #4にて、 PFNにある２つのKubernetesという題名で、Web ApplicationのためにEKSクラスターを運用している話をしました。 スライドはこちらになります。 質問への回答 当日はsli.doでチャットが行われており、私の発表宛てと思われる質問がいくつかあったので回答していきます。 Q. (下の質問とマージします) kubernetesが浸透しているのすごいな。社内向けセミナーとかやってるのかな？ #yjbonfire — ina_ani@帰国 (@ina_ani) November 26, 2019 Q. PFNのバックエンドチームの規模って十分大きいと思いますか？研究者が多いし、インフラが使いづらいと苦情多そう。 使い方のレクチャーだったり、使いやすいようなツールみたいなのは整備されています 社内向けにわかりやすいドキュメントとかが用意

9/22の技術書典７で「OpenAPI 3を完全に理解できる本」を出しました！ https://techbookfest.org/event/tbf07/circle/5637271940235264 具体的な内容はこちら「技術書典７でOpenAPI 3の完全解説本が出ます」で、 電子版はBOOTHで販売中ですのでこちらもどうぞ。 https://booth.pm/ja/items/1571902 なお、正誤情報も具体的な内容が書かれているページに書いてあります。 おかげさまで紙の本は14:50分ごろに完売しました( ﾟ∀ﾟ)o彡ﾟ #技術書典 でのOpenAPI 3の本は紙版が完売しました！！！！ 引き継ぎ電子版を販売しています～ pic.twitter.com/P0NkfxXmm8 — おおた@技術書典い55C (@ota42y) September 22, 2019 「すべてがM(i

docker for macがstartingのまま起動しなくなった。 起動ログに制御文字が大量に出ていた TUIの画面が出てるのではと推測 dockerのttyに繋ぐとブートメニューが出ていたので操作をして解決 Dockerが上の画像の通り、数時間以上starting状態になっていました。 この状態でrestartや再インストールしても解決せず、事実上Dockerが利用不可能になりました。 Docker Desktop for Macの起動時のログ とりあえず起動時のログを調べます。 これは公式サイトのログの撮り方をのままです。 ただし、起動しないのは現在進行形で起きているため、取る期間を1hぐらいに狭めています。 $ pred='process matches ".*(ocker|vpnkit).*" || (process in {"taskgated-helper", "launc

AWS Glueはフルマネージド名ETL(データの抽出、変換、ロード)サービスです。 S3やRDBのデータから、その形式を推定してカタログ登録してくれる機能があり、複数のデータソースを横断して処理するのにとても便利な感じです。 裏はSparkで動いており、SparkやPySparkのコードを書いて実行されるのと、ある程度の処理はWeb上でスクリプトを生成できるため、かなり取っつきやすいです。 Sparkは通常時は起動していないので立ち上がりに時間がかかりますが、Sparkのおもりをしなくて良いのはとても楽で、 バッチ処理といったそこまで応答速度を求められない処理に対してはかなりいい感じでフィットします。 実行のたびにゼロからSparkを起動するJob以外にも、常時稼働する開発エンドポイントやJupyter Notebookが用意されているため、Sparkの処理を自分で書く場合も開発しやすい

マイクロサービスを蝕む負の力学 マイクロサービスアーキテクチャでは、全体を分割し小さいチームとサービスにすることでチームの責任範囲を小さくし、 限られた範囲内で独自にPDCAを回すことで人数の拡大に対しても生産性を落とさないのが利点の一つになります。 これにより個々のマイクロサービスの関心事は小さく保たれるため、構成はシンプルになり実装しやすくなります。 一方でサービス間の依存関係が複雑になったり、通信量コストがとても増えるといったサービス間をまたいだところへの問題、 データの整合性や分散コンピューティングの落とし穴といった分散システム特有の問題、通信先のマイクロサービスの信頼性、安定性といった問題など、マイクロサービスアーキテクチャ全体としての複雑性は上がります。 そして、こういった複雑性や一部のマイクロサービスの不安定さは、そのマイクロサービスを構成する全員に悪影響を与えます。 つまり

「我々はなぜ我々だけなのか アジアから消えた多様な「人類」たち」という本を読みました。 人類の進化の過程を「初期の猿人」「猿人」「原人」「旧人」「新人」の５つに分けた場合、今の地球上には「新人」に分類される我々ホモ・サピエンスしか存在しません。 ただ、過去のある時期には同時期に複数の原人や猿人が入り乱れていた時期があったはずです。 それを化石から読み解き学説を更新していく過程を、最新のアジアの原人たちの例を元に見せていく本です。 だいたい感想としては以下の通りで、人類史全体をザックリと説明した後に、特定のトピックに対して凄く深く書いており、そんなに事前知識無しでも楽しめて凄く良い本でした。 人類の進化についてザックリと説明されている サルから進化したんだよなーぐらいの認識からでも読める 最新の研究成果が生まれる仮定がわかる 化石からどうやって原人の姿を明らかにしていくか いわゆる学説がどう

openapi_parserの0.3.1が出ました。 主に以下の二つの機能が追加されています。 部分的なadditionalPropertiesのサポート discriminatorのサポート 部分的なadditionalPropertiesのサポート OpenAPI 3ではSchema ObjectにadditionalPropertiesという項目を設定できます。 これはBoolean値もしくはSchema Objectを値として持つことができます。 この値がfalseの場合はそのSchema Objectのpropertiesに設定された要素しか持てず、それ以外の要素があったらバリデーションは失敗します。 Schema Objectを設定した場合は、propertiesに設定されていない要素が全てadditionalPropertiesに設定されたSchemaと一致しなければなりませ

株式会社FiNC Technologiesを退職した 株式会社FiNC Technologiesを退職しますに予告を書きましたが、退職しました。 最後にぼくがかんがえたさいきょうのSparkアーキテクチャが無事出来たので、とりあえず満足いく終わりになりました。 Sparkと戯れていた 先週に引き続き、AWS Glueを使ってPySparkで開発をしてました。 様々なテーブルをjoinし、ユーザごとにデータを集計して /user_id/output_name といったパスに一人づつJSONファイルに出力していましたが、これが遅くなった原因でした。 ユーザを何人かのパーティションにまとめ、 /output_name/partition_key といった複数人をまとめて１つのJSONファイルに出力したところ、数時間かかってた出力処理が数分で終わるようになりました。 書き出し対象はS3なので、ネッ