今、IT関連の技術は様々な企業の競争力の源泉です。一方で、実際に企業が必要とするよりもITエンジニアの数は少ないため、採用競争は激化するばかりです。そこで、元ウェブエンジニアでITエンジニアの採用担当を経験した私の視点で、ITエンジニア採用に関する情報をまとめることにしました。 なお、ここでいうITエンジニアはアプリケーションエンジニア、インフラエンジニア、機械学習エンジニア、QAエンジニアなどIT関連エンジニア全般を指します。 # 更新情報 * 2022/05/17 - 公開 * 2022/05/17 - 中途採用前提であることを Chapter 1 に追記 * 2022/05/18 - 誤字の修正 Chapter 15 「行進」 -> 「更新」 ※はてなブックマークでの指摘ありがとうございます * 2022/05/19 - 活用事例の Chapter を追加 * 2022/05/20

こんにちは、インフラの小林です。 GCP環境の監視基盤が一段落し実績も積めてきたので、アーキテクチャについて簡単に紹介します。この記事ではメトリックに焦点を当てています。Prometheusを用いたGCP監視基盤を検討している方や、Managed Prometheusを検討している方の参考になれば幸いです。 アーキテクチャ 比較のためにAWS EKS環境と合わせて紹介します。 AWS (EKS) AWS EKS環境では、監視用EC2インスタンスがあり、k8s Cluster内にはExporterのみが存在します。 k8s Cluster外部からkubernetes_sd_configを用いたService Discoveryを行い、メトリックを回収します。AWS環境はプロダクトによってVM, コンテナの利用がまちまちなため、両ケースに対応できるよう監視インスタンスはコンテナではなくVMとし

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

サーバアプリケーションの運用基盤として、ゲーム領域においてもKubernetesは有力な選択肢です。しかしながら、オンメモリでゲームの状態を管理するようなリアルタイムゲームサーバではサーバへ直接接続する要求もあるなど、Kubernetesの標準リソースによる構成が容易ではない場合があります。 このようなアプリケーションをスケーラブルにホスティングするために、私達は、Google Cloud主導でオープンソースで開発されている、Kubernetes上で専用ゲームサーバを管理するための汎用システムであるAgonesを採用しました。 Agonesの利用により、リアルタイムゲームサーバを運用するための多くの要件を満たすことができますが、マルチリージョンのサポートや、プレイヤーのサーバへの割り当て方法などにおいて、ゲーム固有の要求や特性に合わせた工夫も必要です。 本セッションでは、Agonesを活用

Kubernetes Meetup Tokyo #49で発表したセッション資料です https://k8sjp.connpass.com/event/240993/ 配信URL: https://youtu.be/KOrantQgXkI?t=2258

動画はこちらから https://cadc.cyberagent.co.jp/2022/program/kubernetes-controller-improvements/ 青山 真也 CyberAgent - CIU ソフトウェアエンジニア / KaaS プロダクトオーナー 2016年新卒入社。Kubernetes/CloudNative領域のCA Developer Experts。CloudNative Days Tokyo のCo-chair、Kubernetes Meetup TokyoのOrganizerなどコミュニティ活動にも従事。著書に『Kubernetes完全ガイド』等。 CyberAgent group Infrastructure Unit の Dev チームでは、これまで約 5 年間 Kubernetes を拡張しながらサービスを提供するためのプラットフォームとし

GCP上で Go や Kubernetes, Spannerを活用した開発や運用を、大規模なサービス、チームで実現するにはどうすればよいのか？本セッションでは、DeNA のクラウドネイティブなゲームサーバの開発と運用の取り組みや体制づくりについて紹介いたします。 まず、社内ゲームサーバー基盤Takasho(Go+GCP)を活用し、Kubernetes上にコンテナベースのゲームサーバを構築した開発/運用事例を紹介します。またさまざまな共通部門と協力しつつゲームサーバ開発を行っているため、それらの組織体制なども併せて紹介できればと思います。 データベースにはグローバル規模のRDBであるSpannerを採用しています。Spannerはシャーディング不要でどこまでもスケールさせることができるため、従来のゲームサーバ開発で問題になっていた運用負荷を軽減させてくれています。そんなSpannerの特性を

極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま

0 前章 0.1 概要 聞くところによると業務の8割がソースコードを読む時間らしい。しかし、8割という規模感の割には世間でソースコードの読み方についての議論が活発にされている印象はない上に、体系的かつ順序立てたソースコードの読み方をまとめたWebサイトや書籍も少ない。疑問に思いながらもそれなりに長いことデバッガーを使った読み方・リーダブルコードの内容・Web記事を参照にしてソースコードを読んでいた。 しかし、ソースコードリーディングの方法についての情報がメモアプリ内で散らかってしまい、いつまで経ってもソースコードリーディングの技術が体系的に身についていないと感じた。そのため、本稿では本・Web記事・YouTubeなど媒体を問わず、様々な文献からソースコードを効率的に読む方法をチートシートにしてまとめた。チートシートにする目的は「見返して反復し長期記憶化しやすいようにするため」と「ソースコー

By Yuval Avrahami March 3, 2022 at 5:09 PM Category: Cloud Tags: containers, CVE-2022-0492, Linux, vulnerabilities This post is also available in: English (英語) 概要 2022年2月4日、Linuxはカーネルにおける新たな特権昇格脆弱性CVE-2022-0492を公表しました。CVE-2022-0492はコンテナの基本構成要素であるLinuxの機能、コントロールグループ(cgroup)における論理バグです。この問題は最近発見されたLinuxの権限昇格脆弱性のなかでもとりわけその単純さできわだつもので、「Linuxカーネルが誤って特権的オペレーションを非特権ユーザーに公開してしまった」という内容になっています。 さいわい、ほとんどのコン

ANDPADボードチームの原田(tomtwinkle)です。 Node.jsの mysqljs/mysql の仕様に起因するSQLインジェクションが話題に上がっていたので、それGolangのORMであるGormでも同じような「仕様」があるよ！ という注意喚起の意味も込めて筆を執りました。 ※ 2022/02/21追記 コードレビューを自動化して指摘してもらう記事を公開しました！ tech.andpad.co.jp Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション | 株式会社Flatt Security TL;DR GormのQuery Conditions関数に関する危険な仕様 対策 締め TL;DR GormのConditions関数(Find, First, Delete...)を使用する際、第2引数の値にStringを引き渡

本書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい！！」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日本語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで本書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■本書の構成 本書は以下の構成になっています。 「第1章 DD

codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。

国分太一 @tokioinc_taichi 最近、手土産を用意することが増えました そこで相談です 良い感じの？センスのいい 手土産しりませんか？ もしくは、もらって嬉しいもの ってなんですかねー 2021-05-24 10:08:16 tomjelly🐈🐀かたこりのしゅふ @tomjelly_f8 @tokioinc_taichi 地味かもしれませんが、御門屋の〝揚げまんじゅう〟美味しいですよ！ 程よいサイズ感、常温保存できて生菓子より日持ちする、個包装でスタッフに配りやすい、です✨ 変わり種では、菓匠徳増のマカロンみたいな最中〝丸一口〟生菓子OKなら抹茶シューの〝岩苔〟がイチオシです！（東京から離れますが😓） pic.twitter.com/bByhxlLDFH 2021-05-24 11:30:07

本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し