terraform planの自動化に向けて直面した課題と解決策 - Sansan Tech Blog
はじめに こんにちは！ 技術本部 Bill One Engineering Unit（以下、Bill One EU）の笹島です。 IaC推進チーム（横串チームの1つ）として、CI環境でのTerraform Planの自動化に取り組んできました。 横串チームとは、Bill One EU内の各グループの垣根のない横断チームであり、Bill Oneで抱えている課題を解決するために有志で集まったメンバーによって構成されています。 IaC推進チームとは、文字通りインフラのコード化を推進するチームです。 本記事では、CI環境でセキュアなTerraform Plan自動実行を実現するにあたって直面した課題とその解決策について共有します。 特に、モノレポ環境での複数プロダクト・環境の管理における自動化の課題についても紹介します。 目次 はじめに 目次 前提 ディレクトリ構成とその役割 Workload I
自宅ルータの脆弱性検知システムの開発 - Sansan Tech Blog
Sansan 技術本部 情報セキュリティ部 CSIRT グループの川口です。 2023年4月からセキュリティエンジニアで新卒として、Sansan に入社しました。 現在は ログ基盤（SIEM）のログの取り込み部分の機能修正、問い合わせ対応、インシデント対応などの業務に取り組んでいます。 今回は内定者インターンシップで開発した、自宅ルータの脆弱性検知システムについて紹介します。 目次は以下の通りとなります。 開発に至った経緯 作成したシステム 技術的な話 EDR ポートスキャン チケットシステムへの起票 SOAR まとめと今後の課題 開発に至った経緯 新型コロナウイルスの流行に伴い、リモートワークという言葉をよく耳にするようになったと思います。 弊社でも緊急事態宣言下においては、原則リモートワークとなり、現在はオンライン・オフラインを併用した働き方をしています。 ここで問題となってくるのが自
TerraformによるAirbyteを利用したデータ基盤へのデータ連携とCI/CD - Sansan Tech Blog
こんにちは！「Sansan Summer Internship 2023」でインターンをしていた野首侑作です（X, Facebook）。R&D Architectグループに1ヶ月強コミットしていました。今回のインターンで使った技術はこれまで全く触ったことがありませんしたが、チームメンバーのサポートもあり本番環境でも動かせるコードを書くことができました。 今回学んだことの整理と、Sansanのインターンで学べることの多さを共有したいという意味を込めて、社内ブログでアウトプットしようと思った次第です。 目次 目次 はじめに ローカルでAirbyteの立ち上げ 1. DockerによるAirbyte serverの起動 2. Sourceの登録 3. Destinationの登録 4. Connectionの登録 5. 接続確認 TerraformによるIaC IaCとは Terraformとは
Vol.11 IaC(Infrastructure as a Code)改善チームの立ち上げから半年の活動の振り返り - Sansan Tech Blog
はじめにこんにちは。技術本部 Bill One Engineering Unitの田畑です。 昨年11月に横串チームとしてIaC（Infrastructure as a Code）改善チームが立ち上がりました。横串チームとは、Bill One Engineering Unit（以下、Bill One EU）内の各Groupの垣根を超えた横断チームのことで、Bill Oneで抱えている課題を解決するために有志で集まったメンバで構成されています。*1 IaC改善チームとは、文字通りインフラのコード化を改善するチームで、Bill One EUではTerraformを採用しています。 この記事では、立ち上げから半年間取り組んできた活動内容や今後の展望についてを、活動を振り返りつつ説明します。 なお、この記事は【Bill One 開発 Unit ブログリレー】という連載記事のひとつです。 目次 はじ
Sansan Data Hub・Bill Oneアーキテクト対談：事業を支えるシステムの設計方針を公開【前編】 - Sansan Tech Blog
社内に蓄積された顧客データを整理・統合し、マーケティングに最適なデータに進化させる顧客データ統合サービス「Sansan Data Hub」。そして、あらゆる請求書をオンラインで受け取り、請求書受領から月次決算を加速するインボイス管理サービス「Bill One」。いずれも急成長を遂げており、Sansan株式会社の事業の柱になっているサービスです。 これらのサービスは、データの処理効率やシステムの信頼性などを向上させるために、さまざまなアーキテクチャの工夫が行われています。今回は「Sansan Data Hub」と「Bill One」それぞれの開発の中核を担う千田智己と加藤耕太にインタビューし、前後編の2回に分けて記事化。前編では、両サービスのアーキテクチャ設計の工夫や思想について語ってもらいました。 【Sansan Data Hub】アーキテクチャ解説 ――「Sansan Data Hub」
Eight における AWS Backup - Sansan Tech Blog
技術本部 Eight Engineering Unit（社内通称：Eight EU）の秋本です。普段は Eight をインフラ面からお世話することでご飯を食べています。 酷暑が続いていますね。酷暑は人々の健康を害し、健康が害されると稼動可能な人員が減り、人員が減ると業務負荷が増え、業務負荷が増えるとオペミスが発生しやすくなります。オペミスが発生してもバックアップがあれば最悪なんとかできる事が多く、もはや運用作業にはバックアップ取得が欠かせぬものとなっています。 本項では Eight におけるバックアップ取得の前史を述べ、そのうえで AWS Backup を導入していい感じになった風景を述べるものになります。 AWS Backup 導入まで Eight で使用しているデータの置き場所は以下があります。Eight では現状 AWS のみを使用しています： サービス 用途 S3 名刺画像データ、
今さら聞けないビジュアルリグレッションテストをChromaticで始める - Sansan Tech Blog
Bill One Entry*1グループの秋山です。 1. はじめに 2010年代前半に登場したReactやVue.jsに代表される宣言的UI実装は、大規模なSPAの構築を可能にしました。その一方、フロントエンド領域に新たなアーキテクチャが導入されたことで、それまでWebアプリケーション開発で定石とされたテスト手法を適用しづらいケースが増え、新たなベストプラクティスが求められるようになりました。 その要請に応える形で、2010年代後半にはフロントエンドのテスト手法に緩やかなパラダイムシフトがありました。この記事ではそのパラダイムシフトを振り返りながら、フロントエンドで必要なテストについて考察し、最後にChromaticを用いたビジュアルリグレッションテストを紹介します。 2. Testing Pyramid と フロントエンド テストを語る際によく持ち出されるメタファとして、Testing
人事評価のためのWebアプリケーションを内製化しました - Sansan Tech Blog
人事部 高橋 です。 本記事は Sansan Advent Calendar 2021 - Adventar の10日目の記事です。 このたび、社内で人事評価に使うシステムを内製しました。 このたびと言いつつ1年ほど前から運用が始まっていたのですが、やり残し等も落ち着いたこのタイミングで記事にしてみます。 背景 従来は Kintone に人事評価のためのシステムがあり、4年ほど運用していました。Kintone の設計、カスタマイズは外注でした。 以下の要因から、システムを内製する判断が下りました。 評価設計の定期的な見直しやデータの増加に Kintone のカスタマイズ性と性能が耐えきれなくなった。 今後も人事評価の仕組みは柔軟に（同時に、効率的に入力できるように）見直していきたいという経営陣の意志があった。そのためパッケージを導入するリスクが強かった。 人事部に所属しながらWeb開発がで
Engineering Team Presentation 第二弾「各社のサービス品質を支えるベストプラクティス」を開催しました - Sansan Tech Blog
こんにちは、プロダクト戦略開発室 技術ブランディンググループの相場です。 今回は先日開催した「Engineering Team Presentation 〜各社のサービス品質を支えるベストプラクティス〜」のイベントレポートをお届けしたいと思います。 sansan.connpass.com ご好評いただいた第一弾「各社の事業を支えるアーキテクチャ」に続き、第二弾は「各社のサービス品質を支えるベストプラクティス」をテーマに、ラクスル、DeNA、メルペイ、日本経済新聞社とSansanをあわせた5社からエンジニアが集まり、開発現場における品質向上やプロセス改善のための取り組みを発表しました。 発表1：『加速するサービス展開を支える共通 UI コンポーネント開発』 ラクスル株式会社 ラクスル事業本部 システム開発部（ラクスル） RIU開発5G フロントエンドエンジニア 菅野 彬氏 印刷のラクスルでは
名刺データ化システムをECSに移行した - Sansan Tech Blog
DSOC Infrastructure Groupの藤田です。 最近は汚い牧場物語をやりながらCyberpunk 2077を待つ日々を過ごしております。 私は昨年の11月頃からDSOCで運用している名刺データ化システムをコンテナ化、ECSへ移行するというプロジェクトに携わっていました。今回はその中で躓いたいこと、工夫したことを皆様に共有できればと思っております。 背景、ゴール 名刺データ化システム SansanやEightで取り込んだ名刺は名刺データ化システム(GEES)へ送られてきます。GEESで名刺画像をデータ化、Sansan/Eightへ結果を返して最終的にエンドユーザへたどり着きます。いわばSansan/Eightの屋台骨のような役割を担っています。データ化には様々なプロセスが含まれています。具体的にどんな処理を行っているかはDSOCのウェブサイトでわかりやすく説明されています。こ
プロジェクトの成否を決める非機能要件を定義するには - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部 プロダクトグループの清水です。 直近で非機能要件の定義について頭を悩ませられる事もあったので、改めて非機能要件の定義について記事にしてみました。 非機能要件とは? ビジネス目的を果たす事に成功するソフトウェアには、どのように振舞うかという機能以外にも重要な要素があります。 いわゆる非機能要件とよばれるものです。非機能要件が満たされない場合、機能的には十分だったとしても結果としてソフトウェアがビジネス目的に対して良い成果をもたらせない事になるケースがあります。 例えば、機能要件としてユーザ一覧を表示させる画面を持つWebシステムがあったとします。たとえユーザ一覧を表示できたとしてもレスポンスが極端に遅かったり、何回か表示させるとエラーが返ってくるなど期待する品質が満たせてなかったりすると、ユーザにとってはWebシステムを利用する事に非常にストレスがか
新規事業開発での技術選定の意思と意図 (フロントエンド編) - Sansan Tech Blog
こんにちは、関西支店で新規事業開発室に所属するソフトウェアエンジニアの加藤です。Bill Oneという新規サービスの開発に携わっています。 バックエンド編の続きとして、フロントエンドで私たちが使用している技術やライブラリを振り返って、どんな意志と意図があるかを確認していきます。 Bill Oneは今年の1月ごろにピボットし、それまで開発してきたフロントエンドを全て捨て、1から作り直しました。ピボットの際に改めて技術選定を行い、それまで使っていたライブラリ等を見直したので、本稿ではピボット前後で変化した箇所を中心にフロントエンドの技術選定を紹介します。 前提 改めて前提です。私たちのチームで開発しているBill Oneは今年の5月にローンチしたばかりのサービスで、チームのエンジニアは5名です。開発しているアプリケーションはSingle Page Application (SPA) で、エンジ
新規事業開発での技術選定の意思と意図 (バックエンド編) - Sansan Tech Blog
こんにちは、新規事業開発室に所属するソフトウェアエンジニアの加藤です。私は関西支店でBill Oneという新規サービスの開発に携わっています。 弊社にはSansanのカタチという企業理念があり、働く人々が体現すべきValuesの1つに「意思と意図をもって判断する」があります。ソフトウェアエンジニアとして、意志と意図をもって利用する技術を選定することは当然かもしれませんが、細部までそれを徹底するのは難しいこともあります。本稿では、私たちが使用している技術やライブラリを振り返って、どんな意志と意図があるかを確認していきたいと思います。 などと硬めのことを書きましたが、他所のチームでは普通に使われているライブラリを意外と知らなかったりするので、似たような記事を読みたいなと思って、技術選定を公開してみる次第です。まずはバックエンド編です。 前提 私たちのチームで開発しているBill Oneは今年の
ここ最近の計算社会科学の動向 - Sansan Tech Blog
反対意見を知れば分かりあえるのか？偏った集団でも正しい決定ができるのか？フェイクニュースほど広まりやすいのか？良好な人間関係はパフォーマンスを向上させるのか？研究者が束になってかかれば、社会的現象を予測できるのか？ こんにちは、Sansan DSOC R&D研究員の前嶋です。普段はつながりに効く、ネットワーク研究小話という連載を書いていますが、今回はここ2,3年の計算社会科学の潮流を紹介したいと思います。 計算社会科学(Computational Social Sciences)は、SNSなどのビッグデータ解析やオンライン上での実験などを用いて社会現象を定量的に分析するという、社会科学と計算機科学の融合分野です。 日本でも最近、マシュー・サルガニックによる概説書”Bit by Bit”が翻訳され、社会科学の研究者のみならず、広くその名前が知れ渡りました。日本には計算社会科学研究会というコミ
B2BマルチテナントSaaSの認証にAuth0を使うときに知っておきたかったこと - Sansan Tech Blog
こんにちは、新規事業開発室の加藤です。私たちのチームでは新規事業のプロダクトとしてB2BのマルチテナントSaaSを開発しており、その認証にAuth0を使っています。今回Auth0を初めて使用する中で試行錯誤することが多かったので、最初から知っておきたかったことをまとめておきます。 Auth0とは Auth0はIdentity as a Service (IDaaS) と呼ばれる認証をサービスとして提供するSaaSです。シンプルなID・パスワードによるログインや、Google・Facebookアカウントなどのいわゆるソーシャルログインだけでなく、エンタープライズ向けのG SuiteやAzure AD、SAMLなどのシングルサインオン (SSO) に幅広く対応しているのが特徴です。 なお、Auth0は自社の従業員のID管理にも利用できますが、本稿ではあくまでプロダクト開発者目線で、プロダクトの
DBMSをGoで実装してみた - Sansan Tech Blog
こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか？ データベースの内部実装はどうなっているのか？ トランザクションとはどのようなアルゴリズムで実現されているのか？ NoSQLが遅いのはなぜか？ 古典的なデータベースとは内部的にどのように違うの？ データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかの本やサイトを調べていたのですが、なかでもCMU（カーネギーメロン大学）のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そして本ブログでは、上記の講義
レガシーシステムとつきあう - Sansan Tech Blog
Sansanプロダクト開発部・基盤チームの加畑です。 Sansanプロダクト開発部には、現在約120名のメンバーが所属しています。その中で、私が所属する基盤チームは6名のメンバーで構成されており、データアクセスや認証、メッセージング基盤、CI等開発環境やリリースプロセスなど、アプリケーションの基盤に関わるプロジェクトを主に受け持っています。 担当領域の性質上、システムのレガシー化に向き合う機会が多いです。私を含め複数のメンバーが、常に何かしらレガシー改善に関わるプロジェクトを進めている状況です。昨年の10月に、私が担当したいくつかのプロジェクトについて、レガシーシステムのおそうじという記事でご紹介しました。4月にはレガシー改善に関する勉強会を開催し、はてなさんやYahooさんとも交流することができました。楽しかったです。 前回記事と勉強会では、「レガシー改善のプロジェクトをうまく進めるには
GAEアプリの開発フローにCloud BuildでのCI/CDをいい感じに組み込む - Sansan Tech Blog
関西支店で新規事業開発室に所属する加藤です。私のチームでは、Google Cloud Platform (GCP) で主にGoogle App Engine (GAE) を使ってシステムを構築しています。 GAEはコマンド1つで簡単にデプロイできますが、チームの開発者が増えるにつれて、デプロイ用の設定を共有するのが大変になってきました。 デプロイにも時間がかかって、リリース作業に負荷を感じるようになりました。 そこで、GAEアプリケーションの開発フローに、Cloud BuildによるContinuous Integration (CI) / Continuous Delivery (CD) を組み込み、デプロイを自動化しました。 公式ドキュメントや各種ブログに個別の方法は記載されていますが、開発フローに組み込もうとした時にいくつか考えることがあったので、まとめておきます。 前提 Googl
AWS ECS & TerraformによるSansanの統合監視運用とその仕組み - Sansan Tech Blog
はじめに IcingaとMunin Zabbixへの移行 環境構築 Zabbixの監視内容 監視のリリース方法 リソース配分 バージョンの固定化 本監視システムにおけるツラミ Zabbixの独自仕様に消耗する Zabbixの仕様にインフラ構成を追従している リリース手順の複雑化 サービスの成長に合わせたサイジングやチューニング おわりに はじめに Sansan株式会社プロダクト開発部インフラチームの岡本です。 事業欲求に応じ優先度と軽重が決められたタスクに向き合いつつ、チームへの依頼事項に対し日々柔軟に対応するよう努めています。 また、Sansanサービス全般のインフラ運用・保守を行いつつも、併せて運用業務の撲滅に取り組んでいます。 今回は、Sansanサービスにおける監視ツールの導入経緯からインフラ構成、監視の設計方針、リリース方法、本構成におけるツラミ等をお伝えできればと思います。 I
エンジニアキャリア論（エンジニア type 対談後記） - Sansan Tech Blog
CTO の 藤倉 です。 エムスリー株式会社で VPoE をされている山崎さんとエンジニアのキャリアについて対談させていただいた記事が、エンジニア type さんで先日公開されました。この企画の裏側や、記事の中では伝えきれなかったことについて書いてみたいと思います。 type.jp そもそもこの対談企画、山崎さんと「一緒に何かやりたいですねー」という軽めのノリで始まっています。山崎さんとはここ一年くらいの間でお会いする機会が何度かあり、お互いに考えが一致するところもあって意気投合しました。エムスリーさんは医療系の SaaS ビジネスを展開されており、ビジネス向け SaaS を提供する Sansan とは雰囲気が似ているところがあります。特に、エンジニアの採用や育成という部分では共通することが多い。そんな会話をしている中で、企画が立ち上がっていったのでした。 私は 20 年以上の間、ソフトウ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
