CloudNative Days Tokyo 2023 での登壇資料です

で、GitHub Sponsorsを始めたところ多数のご支援をいただくことができたことを書きました。 その後、OSS活動を細々と続けていたところ、JavaScript/TypeScript ランタイムであるDenoの開発を行っている Deno Land Inc.にジョインすることになりました。 ジョインまでの流れ 上記の記事で書いたように、deno_lint などのDeno関連のプロジェクトにコントリビュートをしていました。定期的にコントリビュートしていると、他の人からのPull Requestのレビューなどもお願いされるようになります。Approveをすることはできますが、mergeの権限はありませんでした。その他にも、issueをクローズするための権限もなく、整理のためにクローズしたいissueがあっても、メンテナに依頼をする必要がありました。 大した手間ではなかったものの、メンテナ権

最近アラサーになりソフトウェアエンジニア (SWE) として正社員として働いているが、いろいろ辛くまた転職してきたくなってきた。 openworkなどで会社を漁っているが、エンジニアの理想郷がどこになるのか悶々としている (もちろん人それぞれだが..) 今までの会社としては 外資IT → 大手メーカー の2社で、現在の年収は 800 ~ 900 万ぐらい。 今はアーキテクト/ SM / Tech Lead らへんの業務をしていて、将来的には エンジニアリングマネージャー をしたいと思っている。 転職先には以下があると思うが、どれがいいんだろうか。 1) Web企業やりたいことは一番できそうな気がしているが長期的な自分のキャリアを考えたときに、平均年齢が低いことや退職金がないため不安が大きい。 また勢いはあり多くのビジネスを創出しているがどれも規模として小さいものが多いかつ、 またグローバル

はじめにタイトルの通り最近「ソフトウェアエンジニアがビジネスの話をする」って極論かなり難しくねと思っており、まだまだ自分の中にも答えはないが書いてみる。 逆に読むと良い記事、書籍、論文があるなら教えて欲しい。 背景近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 これは本当に良いことだと思っていて、技術や業界全体の経験の積み重ね、研究活動によって、技術やノウハウがコモディティ化したことで、より本質的なエンジニアリングが提供すべき事を考えられるようになっている結果の1つだなと思う。私がエンジニアリングを最初に学んだ頃なんかは、ソフトウェアエンジニアはキツいみたいな文脈で3K職だと言われていて、高専でも「電気系に行ったほうが安泰だぞ」と先生が言うほどだった。GitHubやCI/CD、クラウド、OSSだったり

The Go gopher was designed by Renée French. Illustrations by tottie. ©tottie / Renée French https://github.com/tottie000/GopherIllustrations/blob/main/Gopher_Illustrations/scuffle.pngIntroductionIf you are a Go developer and you’ve ever encountered the problem that your process memory usage doesn’t decrease even when your objects are definitely freed, This post is for you. In this blog, I’ll expla

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEで働くエンジニアにいろいろと話を聞く「LINE Engineer Insights」。LINEの技術組織で働く個々人に、何を重視して技術者としてのキャリアを歩んでいるのか、今LINEで何に取り組んでいるのか、今後実現したいことなどを聞いていきます。 今回登場するのは、Observability Infrastructureチームに所属する坂本大将です。「大規模なシステムの可用性・信頼性を保ちつつ、開発・運用することに強い興味がある」と語る彼。その言葉の通り、坂本は2021年にLINEに入社して以来、プライベートクラウド「Verda」の監視基盤を担当した後、社内異動制度を利用して現在は時系列データベースの構築・運用などを

Fluentd実践入門 Fluentdの現バージョン(v1.15)について世界で一番詳しい本です。というか、Fluentdそのものだけについての、おそらく世界で唯一の技術書です。 出版社は技術評論社です。電子版もGihyo.jpやKindleはじめ各社で出ます。買ってね! gihyo.jp TL;DR 発売日は10月8日です 一部書店ではちょっと早く9月末に並ぶかも 電子版は発売日よりちょっと前に出るかも1 544ページ、Fluentd本体については考えられる限り盛り込みました Fluentdをなんとなく使っている人が確信を持って使えるようになれるはず 組込みプラグインの頻出用法、本番環境での運用ノウハウ、プラグイン開発からテストなどまで エコシステム的な部分についてはカバーできていません Kubernetes上での運用やFluent Bitとの組み合わせとか AWS FireLensやG

NTT Tech Conference 2022 での「Dockerからcontainerdへの移行」の発表資料です https://ntt-techconf.connpass.com/event/241061/ 訂正： P2. . 誤: ``` Ship docker run -it --rm alpine Run docker push ghcr.io/ktock/myalpine:latest ``` 正: ``` Ship docker push ghcr.io/ktock/myalpine:latest Run docker run -it --rm alpine ``` Read less

Webのフロントエンド開発言語として真価を発見されたJavaScriptは、数年後に今度はサーバーサイド開発言語として再発見されます。しかし、その立役者となったNode.jsの作者ライアン・ダール（Ryan Dahl）はNode.jsの開発を離れ、新しいJavaScript実行環境としてDenoを生み出しました。 ▶ Deno - A modern runtime for JavaScript and TypeScript 今回お話しを伺った日野澤歓也（@kt3k）さんは、2018年からオープンソース活動としてDenoにコントリビュートを重ねた結果、作者のライアン・ダール自身にリクルーティングされ、2021年1月にその開発会社であるDeno Land Inc.にジョインしました。現在はフルタイムのOSS開発者として勤務しています。 JSConf JP 2021における日野澤さんの発表「De

Grafana Loki is an awesome log monitoring platform provided as OSS. However, it is hard to run in production because it is constructed with many microservices and we can't know how they work easily. I aim to complement the official document and make the readers plan capacity, select parameters, and run Loki stably by themselves to provide this book. This book shows you the following knowledge. You

今回はビジネス系ではなく、英語学習系の記事になります。実は私、20代のころにTOEIC満点を獲得しているバイリンガルでして、英語のミーティング参加やメール作成などの仕事もこなしています。 今年はNFTやメタバースといったweb3の台頭、SaaSグローバル企業との競争など英語に触れる機会も多いので、私が日本にいながら英語力を落とさないためにやっている勉強法をまとめてみました。 今年こそは英語やるぞ！と思っている人はぜひどうぞ。 前提：99％の英語学習者が誤解していること私が今まで出会った中で99％の人が知らない、けど英語ができる人はやっているポイントがあります。それは英語学習というものは「自分が発音できる英語しか理解できない」です。どういうことでしょうか？ 例えば、こちらの単語を見てください。正しく発音できますか？ month これは「月」という意味ですね。2月や12月という月です。発音は「

2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで坂本大将氏が、LINEのプライベートクラウド「Verda」でログ収集する上でのポイントについて共有しました。後半は「Managed Fluentd Cluster」の導入について。前半はこちら。 Managed Fluentd Clusterの導入 まず複数のチームが、自分たちのログ設定を我々のManaged Fluentd Clusterに適用することを想定してみます。 あるチームが設定を適用する時に他のチームも同じように適用しようとすると、コンフリクトが発生する可能性があります。またあるチームが設定的に間違っている設定を適用しようとした時に、Fluentdのプロセスが壊れてしまってダウンタイムが発生してし

2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで坂本大将氏が、LINEのプライベートクラウド「Verda」でログ収集する上でのポイントについて共有しました。前半は「Verda」でログ収集する上での課題について。 LINEが内製しているプライベートクラウドプラットフォーム「Verda」 坂本大将氏：それでは「Reliable Logs Aggregation System in Multi-Tenant Kubernetes cluster」というタイトルで発表し たいと思います。 まずスピーカーの自己紹介からします。私は坂本大将と申します。2021年1月にLINEに入社していて、以来VerdaというプライベートクラウドのSREを務めています。ミッションとし

CloudNative Days Tokyo 2021での登壇資料です https://event.cloudnativedays.jp/cndt2021/talks/1252

LINEユーザーとビジネスの価値をつなぐためのSREとは、いったいどんなことをするのか。LINEの7つの領域から9名が登壇し、業務内容や体制、開発における課題、働く個々人のやりがいなどについて話します。萬治渉氏は、社内プライベートクラウド「Verda」のSREについて紹介しました。 プライベートクラウド「Verda」について 萬治渉氏（以下、萬治）：「Verda Reliability Engineeringチーム」の紹介を始めたいと思います。萬治渉と言います。よろしくお願いします。Verda Reliability Engineeringチームのマネージャーをしています。 5年くらい前に新卒でNTTに入って、OpenStackなどのプライベートクラウドや、あとはネットワーク機器の設定の自動化などの研究開発に携わったあと、LINEに入社して、Verda Reliability Engine

本記事について Fluentdは機能としてはシンプルですが、 高負荷環境で安定的に運用するためにはある程度の知識が求められます。 そこで、本記事ではそれなりにログ流量の高い環境下で私が考慮した観点をまとめました。 本記事では、KubernetesでFluentdの信頼性を担保するための3つの観点に加え、 「高負荷時の安定運用」に焦点を当て、 負荷分散 適切なモニタリング トラブルシューティングとチューニング の3つの観点について整理しています。 前提となるアーキテクチャ アーキテクチャとしては実際に私が構築した図の構成を前提とします。 アーキテクチャの特徴 1つのKubernetesクラスタに、FluentdがForwarderとAggregatorという2つのロールで存在しています。 Forwarder DaemonSetでデプロイされる 各コンテナの出力ログをあつめ、Aggregato

本記事について Lokiについてまったく知識のない状態の人にとって、1からキャッチアップしていくのは とても大変なことです。 特にLokiはマイクロサービスで構成されているため、何を知るべきなのかの全体像が見えにくいと思っています。 そのため、Lokiをまったく知らない状態から実際に運用検証を開始するために必要なインプットを体系的にまとめました。 具体的には下記の項目で整理します。 Lokiの機能 Lokiを構成するアーキテクチャ Lokiを構成するプロセス Lokiのモニタリング Lokiでのログのリテンション管理 Lokiのデプロイ Lokiでのデータキャッシュ Lokiのベストプラクティス ※前提として、Prometheusについての基本的な知識があれば本記事についてもすぐに理解できるかと思います。 1. Lokiの機能 Grafana Lokiとは？ Lokiは3大監視項目である、

概要 Fluentdで障害設計をする上でバッファリングの概念は切っても切り離せません。 本記事では、ドキュメントだけでは拾いきれないものも踏まえ、 Fluentdのバッファリングで抑えておくべき情報を体系的にまとめます。 バッファリングとは？ Fluentdではログをバッファリングしてまとめて送信するための仕組みが用意されています。 これは下記のような用途に用いることができます。 送信先がダウンしていたときに一時的に保管しておく 送信先のキャパシティに合わせて送信流量を制限する Fluentdにはメモリ上、もしくは永続化ディスク上にバッファを保管しておく仕組みが用意されています。 バッファの構造 バッファの構造は下記のようになっています。 引用: https://docs.fluentd.org/buffer Output Pluginごとに一つバッファ領域を持っており「stage」と「q

概要 GKEなどを使えば自動的に標準出力のログが集計&集約され、Cloud Loggingなどを通して可視化されますが、 オンプレミス環境でKubernetesクラスタを構築する場合そうはいきません。 また単純なアプリケーションログの集計以外にも、 Kubernetesを使ってログ、データ集計をしている人はFluentdを運用しなくてはならない人は多いと思います。 本記事では、ログの集計、集約のデファクトスタンダードであるFluentdをKubernetes上に展開する上で、 信頼性を担保するための観点を整理します。 想定アーキテクチャ 想定アーキテクチャとしては現場でよく構築されている、図のような構成を用います。 アーキテクチャの特徴 クラスタに、FluentdがForwarderとAggregatorという2つのロールでそれぞれ存在しています。 Forwarder DaemonSetで

この記事はKubernetes Advent Calendarの7日目の記事です。 今回は、Kubernetesのマルチクラスタ化についての考察記事を書きます。 マルチクラスタの定義 マルチクラスタと一重にいっても色々とありますが、本記事では、「複数のKubernetesクラスタを並列に並べ、トラフィックを特定の条件でそれぞれにルーティングする」構成のことを指すとします。 また常時マルチクラスタではなく、普段はシングルでも、いつでもクラスタを並列に並べることができる構成もマルチクラスタ構成とします。 マルチクラスタが必要になるケース 運用する側としては、クラスタの数は少なければ少ないほど嬉しいはずです。 では、どのようなケースでマルチクラスタ構成を取る必要が出てくるのでしょうか？ Multi-cluster use casesにも記載されていますが、コアなものに絞って要約すると、下記のよう