こんにちは、Web Engineer の @wozaki です。 今回は、採用プロセスの改善として、職務経歴書に記載いただきたいことを公開した背景をご紹介します。 概要 職務経歴書に、採用チームとして期待する情報が不足していることがある 不足すると、以下の課題が発生することがある 書類選考は通過するが、その後の選考でミスマッチと分かる (経歴書が充足していたら、より早期にミスマッチが分かったかもしれない) 面接の前に経歴に踏み込んだ質問を設計できずに、面接時間内でマッチしているか情報を引き出す難易度が上がる 既存の対策として、情報の追記をお願いすることがある 新たな対策として、記載いただきたいことを ガイドとして公開 することにした 記載いただきたいこと 早期ミスマッチ解消の必要性 Web Engineer の採用は競争が激化している肌感があります。 応募者の方々にとっても、様々な企業の中

はじめに こんにちは！ モジュール開発部の yamakazu (@yamarkz) です。 あけましておめでとうございます。2023年もよろしくお願いします。 本記事が新年最初のプロダクトブログになるのですが、何を書こうかとても迷いました。笑 抱負的な何かが無難だと思いつつ、1年先のことまでは見通すことができない。10Xはドラスティックに事業や組織が変わるので、中長期な目線で1つのテーマを説くのは難しいなと。そう色々と考える中で、ちょうど足元で成果が出始めている具体の取り組みを紹介したい！というモチベーションが生まれてきました。 なので今回は、半年先までの将来的な抱負の意図を交えながら、直近の取り組みで手応えを感じ始めている、アーキテクチャ改善のプラクティスを紹介しようと思います。 具体的にはタイトルにもある”適応度関数”と呼ばれるプラクティスで、巷では概念としては認識されているものの、ま

はじめに EKS のバージョン更新時のメンテナンスは必要？ Kubernetes は何をする？ バージョン更新時に考慮すべきこと 1. Manifests のサポートが切れる 2. Helm などで導入しているサードパーティのサポートが切れる 3. EKS Addons 具体的な対応内容例 4. AMI のバージョン更新 まとめ はじめに こんにちは、 Gunosy Tech Lab 所属の hyamamoto です。 もう 2 月ということで時間の流れが早いことをひしひしと感じています。 さて、EKS のバージョンアップの季節がやってきました。 皆さん EKS の更新は無事済ませましたか？ それともすでに今回バージョンは終わらせて悠々と過ごされていますか？ 便利な EKS ですが、バージョンアップ作業には定期的に向き合う必要があります。 一方で、バージョンアップ作業とそれに伴うメンテナン

こんにちは。研究開発部Architectグループ、ML Platformチームの神林です。ML Platformチームは主に研究開発部の成果を最大化するための基盤開発を行っているチームです。この記事では、Kubernetes(EKS)を導入することになった経緯や、周辺技術の選定、運用する上で必要な設計について書いていきます。 導入の経緯 研究開発部では、プロダクトのコアな技術を開発している特性上、プロダクト組織からの要求等で、絶え間なく新しい機能を提供していく必要があります。私達Architectグループのエンジニアは、新しい機能提供のためのインフラ構築を行っていますが、毎回0からアーキテクチャ設計を行っていたため、構築するためにそれなりに大きな工数をかけていました。また、デプロイ方法もCodeBuild、CodePipeline、GitHub Actions等様々なサービスを使っており、

はじめに こんにちは、クラウド&ネットワークサービス部で SDPF のベアメタルサーバー・ハイパーバイザーの開発をしている山中です。 先日 GitHub Actions self-hosted runners のオートスケーリング構成の紹介（クラウドサービス開発を支える CI の裏側） の記事で、自作の runner controller と Docker を用いた、オンプレミスでの CI 環境構成についてご紹介しました。 今回の記事では、構築した CI 環境上で動かしている workflow の紹介をしながら、workflow 作成についての Tips をいくつかご紹介したいと思います。 engineers.ntt.com 記事を書いたモチベーション 実際の業務で GitHub Actions を使用するにあたって、ありがちな悩みを解決するための workflow の作成事例や工夫などの

※この記事は 開発生産性 Advent Calendar 2022 カレンダー2 の20日目の記事です。 前回記事の16日目は nakayamaatsushiさんの 『Findy Team+ Award 受賞の裏側~開発生産性向上の取り組みを振り返る~』でした。計測した開発指標をどのように開発生産性向上に結び付けているのか、具体的なアクション事例が紹介されており非常に参考になりました！ この記事の内容 カナリアリリースを導入しました やってみての感想 うまくいったこと デプロイ頻度が上がる 本番で発覚するバグのユーザー影響を抑えられる 試しやすくなる 期待通りじゃなかったこと 開発リードタイムが短縮される⇒それほどでもない 機能開発のスループットがあがる⇒べつに上がらない マージが分散することで、衝突が起こりづらくなる⇒ならない 本番環境での不具合は発生しなくなる⇒そうとはいいきれない わ

この記事は Sansan Advent Calendar 2022 19日目の記事です。 前日は fujisyo32 さんの zenn.dev でした。 今年は特に画像周りで拡散モデルの話題で持ち切りでしたね。言語生成周りの研究も非常に興味深いです。 はじめに 私が所属する研究開発部では、Python のパッケージマネージャとして Poetry を標準的に利用しています。 github.com Rust のように toml でパッケージを人間が認識しやすい形で管理できる点は非常に魅力的であり、setup.py, requirements.txt, setup.cfg, MANIFEST.in 等を代替できるため非常に便利です。 しかしながら最近、Poetry を用いたインストールやパッケージ追加等の依存解決に凄まじく時間を要しており、なんとか速度削減して開発のサイクルを早めることは出来ない

こんにちは、R&D Architectグループの辻田です。ECS on EC2のアーキテクチャでサービスを構築する機会があったので、そこで得た知見をTips形式でまとめたいと思います。 EC2 or Fargate ECSはEC2とFargateの2つの起動タイプをサポートしていますが、今回はサービスの背景やユースケースの観点からすべてのタスクをEC2で起動することになりました。 EC2 or Fargateはそれぞれメリットデメリットがあり、どちらが最適かはユースケースによって様々です。ざっくり判断基準を上げると EC2インスタンスのスペックやOS、ミドルウェアなど細かいカスタマイズが必要か EC2インスタンスの継続的な管理が可能か リソース使用量が予測でき、最適なインスタンスタイプを選定できるか などが大切なポイントになると思います。 例えば、新規サービスなどでどれくらいの負荷がくるか

背景 FastAPIでは以下のようにデコレータ関数を使うことでHTTPサーバのpathを設定することができ、これをPath Operationと呼びます。 from fastapi import FastAPI app = FastAPI() @app.get("/") async def read_root(): return {"Hello": "World"} @app.get("/items/{item_id}") async def read_item(item_id: int, q: str = None): return {"item_id": item_id, "q": q} このPath Operationでdefを使うべきかasync defを使うべきかの方針を説明します。 環境 Python 3.9.11 FastAPI 0.74.1 方針 結論から言うと以下の方針で

はじめに 非同期処理のことから知らない人向けにPythonくらいしかろくに知らない人間が書きました。せっかくキーワードが文法に組み込まれたんだから理解したいじゃんか！ asyncioモジュールを使うための基本的な概念が理解できるようになってるはず、多分。 環境としては Python3.5 以上を想定しています。つまり、await や async キーワードを使っていきます。 それから、関数やメソッドの仮引数は全く書いてません。必要最低限は文中で説明していますが、より完全に知りたい人は適宜ドキュメントの参照をお願いします。 主役はループちゃん asyncioの主役はイベントループです。イベントループは頼まれた仕事を順番にどんどん処理していくデキるクールガイです。 本質的に、私たちはイベントループに仕事を関数オブジェクトの形で与えていくだけです。asyncioモジュールの大部分は、私たちが仕事

Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P

こんにちは。 技術本部研究開発部の高橋寛治です。 SageMakerのInf1推論エンドポイントで機械学習モデルを試したので紹介します。 部分的に紹介しているため、SageMakerやHuggingFaceを使ったことがないと、わかりづらいかと思いますがご了承ください。 目的 現在SageMakerの推論エンドポイントで、独自コンテナの機械学習モデルを稼働させています。 これをコスパよく、より高速に動かしたいというのが今回の目的です。 Inf1インスタンス Inf1インスタンスは、機械学習の推論に特化したAWS Inferentiaチップを搭載したインスタンスのことです。 GPUインスタンスよりもスループットが高く、推論あたりのコストが低いことが特徴です。 Inf1インスタンスで上記の恩恵にあずかるために、「モデルのコンパイル」と「推論環境の構築」が必要となります。 モデルのコンパイル 今

広告技術部のUT@mocyutoです。 大幅コスト削減シリーズ第二弾です。 前回はこちら tech.gunosy.io 今回はアベイラビリティゾーン（AZ）間通信のコストをIstioのlocality load balancingを使って削減した話になります。 概要 Istioとは どのようにコスト削減したか まとめ 概要 みなさんはマイクロサービスを導入しているでしょうか？ 最近はモジュラモノリスが流行り始めている雰囲気を感じてきていますが、弊社の広告配信サーバは以下のようなマイクロサービス化された設計（と言っても2つのサービスしかないのですが）になっています。 構成図 一般的にクラウドプロバイダ上で構築している場合、耐障害性を高めるために複数AZ、複数リージョンに分散させることが基本になるかと思います。 弊社では、単一リージョン複数AZに分散させて稼働しています。 リージョン間の通信に

環境 やりたいこと 構築 動作確認 タスクの起動 結果 何が起きていたのか 前提知識 考察 タスク開始までのリードタイムを短縮する キャパシティプロバイダの｢minimumScalingStepSize｣ 説明 Terraformでの設定箇所 ASGの｢最小キャパシティ｣ 説明 Terraformでの設定箇所 キャパシティプロバイダの｢ターゲットキャパシティ｣ 説明 設定にあたっての注意 Terraformでの設定箇所 各設定値変更のユースケース まとめ 補足事項 参考文献 AWS ECS クラスター Auto Scaling (CAS)を活用したECSクラスタ(GPUインスタンス利用)を、Terraformを使って構築した。 環境 ・Terraform：1.0.8 やりたいこと 以下を実現したい。 イベントを契機にある処理をしたい。 イベントの発生頻度、量は予想が困難。 イベントが大量に

最近, 仕事と休日に関して考え方を変えることでだいぶ楽になったのでそれをここに記す. まえがき 私のやっている仕事には, 仕事とも趣味とも取れるような中間的なタスクが存在している. 周りのみんなは, その中間的なタスクを休日にもやりたくてやっている人が多い. (楽しい人には楽しいみたい) しかもそこで成果を発揮すると会社に評価されるのだ. これまでの考え方 周りのみんなはその中間的なタスクで成果を残している人たちばかりで, 自分も早くそうしなくてはいけないと思って, 休日にもやらなきゃいけないという義務感が強かった. (入社前に成果を出している人もいる状況) そんな状況なので, 休日で外に鳥見に行くと, 「こんなことやってていいのかなぁ」とか, 休んでいるときも, 「やらなくちゃ」という考えがずっと頭にあり, 全然リラックスできなかった. 改めた考え方 そんな義務感の中で日々を過ごすのはそ

データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @