開発・検証用にintdashサーバーを動かしたいエンジニアのみなさん、 こんにちは、ソリューションアーキテクトの伊勢です。 intdashの2025年版からDockerでサーバー環境を構成できるようになりました。 製品マニュアルページで サーバーの構築 の1パターンとして AWS EC2上のDocker（簡易環境） の構築手順を公開しています。 1 今回はその理解を助けるため、各ステップの目的・準備・結果確認を噛み砕いてintdash環境を構築し、サーバーのログや設定を確認してみます。 2 はじめに 全体の流れ サーバー構成 AWS CDK 構築手順イメージ 手順前提 ツール準備 環境構築 準備 EC2インスタンス構築 アプリ起動 起動確認 SSLサーバー証明書設置 サーバードメイン名の準備 Let's Encryptで証明書設定 メールサーバー設定 管理者ユーザー設定 Google Maps APIキー設定 計測開始 intdash Motion起動 ログ確認 確認コマンド 計測時のログ確認 WebSocket接続 計測新規作成 アップストリーム開始 基準時刻受信 データ伝送 計測停止 負荷確認 AWSコンソール top コマンド 設定 設定確認 設定変更 バックエンド：ログイン試行回数変更 フロントエンド：ロゴ変更 おわりに はじめに 全体の流れ 全体像を捉えられるようにサーバーの構成から説明します。 サーバー構成の説明 EC2上にDockerでintdashサーバーを構築 ブラウザ・Motionから接続確認 データ送信とログ確認 負荷・データ・設定の確認 サーバー構成 通常、intdashのサーバーサイドは、2種類のインスタンスで構成されます。 3 APIインスタンス Webサーバー、API、認証、データ伝送、データやメディア管理 DBインスタンス ユーザー／エッジ／計測の保存、計測の時系列データの保存 通常のインスタンス・サービス構成 簡易環境では、1つのEC2インスタンスにAPI/DB双方のサービスが同居します。 4 EC2簡易環境 AWS CDK 簡易環境の構築にはAWS CDK（AWS Cloud Development Kit）を利用します。 AWS CDKとはインフラ構成をコードで記述したもので、このコードは AWS CloudFormation のテンプレートに変換されます。 AWS CloudFormation は、インフラ構成を定義したテンプレートで自動的に構築・更新・削除するサービスです。 CDKで生成したテンプレートをもとに CloudFormation がインフラを構築・更新・削除を自動化、状態を管理します。 構築手順イメージ 構築手順は大まかに ①〜③インフラ構築 ④〜⑥アプリ構築 にわかれます。 構築手順 作業用PC AWS CDKでテンプレートを生成してCloudFormationを起動します。 AWS CloudFormation テンプレートと元にAWSリソースを構築します。 EC2インスタンス Docker Composeで各サービスのコンテナを構成・起動します。 コンテナ構成定義から環境変数を読み込みます。 手順前提 事前に以下が必要です。 作業用PC AWS CLI、およびAWS CDKを実行します。 マニュアルのコマンドはLinux準拠です。 5 AWSアカウント EC2などのリソースが構築されるAWS環境です。 AWS IAMユーザー 作成するAWSリソースに権限が付与されている必要があります。 intdashライセンス アクティベーションキー intdashサーバーを有効化するため、設定します。 intdashライセンスを契約すると発行されます。 サーバードメイン名 サーバーにFQDNでアクセスするために必要です。 今回はAWS Route53で払い出す手順を紹介します。 ツール準備 作業用PCに必要なツールがインストールされているか確認します。 AWS CLI EC2へのSSH接続時、AWS CDK実行時の認証に使います。 Node.js Node.js 本体のバージョン管理ツールです。 npm パッケージを実行ツールです。AWS CDKスクリプトを実行します。 aws --version node -v nvm --version npm --version Node.jsのバージョンが古かったので最新版をインストールしました。 AWS CLI、Node.js / npmの確認 環境構築 準備 マニュアルの通り、以下を準備します。 6 AWS CLIの認証情報 キーペア作成、AWS CDKデプロイ時の認証のために設定します。 AWS CLI認証情報 EC2インスタンス構築 ここからインフラ構築を始めます。 まず、作業用PCで実行するデプロイ資材をダウンロードします。 CDK資材ダウンロード インタラクティブモードでAWS CDKのセットアップを開始します。 セットアップ開始 今回、intdash最新バージョンにあわせてRocky Linux 9イメージを使用します。 7 rockylinux.org Version: 9.7 Region: ap-northeast-1 Architecture: x86_64 Rocky Linux9.7イメージのAMI IDをコピー 確認したRocky Linux 9イメージのAMI IDを指定してデプロイします。 また、削除時のElastic IP保持を指定しています。 Elastic IPを確認 生成されたペアキーを安全な場所に置き、 EC2インスタンスにログインできるか確認します。 mv ./intdash-trial-key.pem ~/.ssh ssh -i ~/.ssh/intdash-trial-key.pem rocky@ < Elastic IP > sudo su - intdash ログイン確認 アプリ起動 セットアップが完了すると、すでにintdashサーバーが起動しています。 起動確認 ブラウザで https://intdash.<Elastic IP>.nip.io にアクセスします。 ログイン画面 ログインしてProject Consoleが表示されることを確認します。 Project Console画面 もしアクセスできない場合はログを確認します。 # ステータス確認 sudo systemctl status intdash-trial Docker Composeの全コンテナのログを確認する方法です。 auth-1 などコンテナ名が表示されます。 # リアルタイム表示 journalctl -u intdash-trial -f # 直近100行 journalctl -u intdash-trial -n 100 # 直近10分 journalctl -u intdash-trial --since " 10 minutes ago " 全コンテナログ ログインできない場合、Authentication Serviceのログを確認します。 特定コンテナのログを表示する方法です。 Docker Composeのサービス名 auth を指定します。 cd ~/deployment/ # 直近100行 docker compose -f docker-compose.yml logs auth | less # 直近10分 docker compose -f docker-compose.yml logs auth --since 10m | less 特定コンテナログ SSLサーバー証明書設置 このままではHTTPS通信ができません。 ブラウザではアクセスできますが、今回エッジとして利用する intdash Motion でアクセスできません。 続きの手順でHTTPS通信できるようにします。 SSLサーバー証明書設置前 今回は以下のように準備しました。 サーバードメイン名 今回はAWS Route 53で取得します。 サーバードメイン名の準備 本記事用に取得しています。 AWS Route53でドメイン名を購入します。最安で$15/月です。 ドメイン購入 登録に数分かかります。 完了するとVerifyメールが届きます。クリックします。 ドメイン登録のVerifyメール EC2インスタンスのIPアドレスを割り当てるサブドメインのレコードを作成します。 サブドメインレコード作成 全世界のDNSサーバーに登録が開始され、しばらくすると名前解決できます。 8 dig < サブドメイン名 > 名前解決成功 Let's Encryptで証明書設定 EC2インスタンス上でHTTPS通信のための証明書・秘密鍵を生成します。 Let’s Encrypt の証明書発行ツール Certbot をインストールする前に、Rocky Linuxのパッケージ管理コマンド DNF（Dandified Yum） で追加パッケージリポジトリ EPEL（Extra Packages for Enterprise Linux） をインストールします。 sudo dnf install -y epel-release sudo dnf makecache EPELインストール マニュアル通り、Certbot でSSLサーバー証明書と秘密鍵を発行します。 SSLサーバー証明書・秘密鍵発行 intdashサービス起動の前に、デプロイ資材の環境変数 FQDN を取得したサブドメイン名に変更します。 FQDN変更 これで intdash Motion でHTTPSアクセスできるようになります。 intdash MotionでHTTPSアクセス メールサーバー設定 マニュアル通りにメール設定を環境変数に追加します。 元の AUTH_SMTP_ADDRESS: " mail:1025 " AUTH_SMTP_HOSTNAME: " auth " はコメントアウトします。 9 メールサーバーと通知メール送信元を設定 AUTH_SMTP_PASSWORD に設定する <Gmail用のアプリパスワード> は Googleアカウント > 2段階認証プロセス > アプリ パスワード で発行します。 アプリパスワードの発行 管理者ユーザー設定 マニュアル通り、管理者ユーザーのメールアドレスを登録します。 メールアドレス追加 確認メール メールアドレス確認済み Google Maps APIキー設定 Google Maps APIキーを準備します。 Map JavaScript APIを有効化します。 自サイトだけで利用できるようウェブサイトでアプリケーションの制限を設定しておきます。 Google Maps APIキー準備 あとはマニュアル通り、Google APIキーを設定します。 Google Maps APIキー設定前 Google Maps APIキー設定後 計測開始 intdash Motion起動 intdash Motion の計測を起動します。 アップストリームを Edge Finder 、作成された計測を Meas Hub で確認します。 Edge Finderの確認 Meas Hubの確認 ログ確認 確認コマンド 全コンテナのログは journalctl で確認できます。 journalctl -u intdash-trial -f journalctl -u intdash-trial -n 100 journalctl -u intdash-trial --since " 10 minutes ago " 各テナントのログはDocker Composeの logs コマンドで確認できます。 cd deployment/ docker compose -f docker-compose.yml logs < container > | less docker compose -f docker-compose.yml logs < container > --since 1h | less なお、本構成では特にDocker Composeのロギング設定をしていません。 10 計測時のログ確認 計測起動時のBroker Serivceコンテナのログを確認してみます。 docker compose -f docker-compose.yml logs broker -f Broker Serviceコンテナログ WebSocket接続 Motionで計測を開始すると、一度WebSocketが切断されます。 "msg":"Received Disconnect" その後、改めてWebSocketの接続ログが出力されます。 "msg":"Received WebSocket:\tua:Motion/49 CFNetwork/3860.400.51 Darwin/25.3.0 referer: remote_ip:xxx.xxx.xxx.xxx:46928 proto:HTTP/1.1" "msg":"Received ConnectRequest request_id:0 protocol_version:2.0.0" "msg":"Authenticated by OAuthToken subject:c82b7aba-b9e1-46a8-a8b4-87c7384ce140" 計測新規作成 "msg":"Received","tenant_id":0,"project_id":"00000000-0000-0000-0000-000000000000","user_id":"c82b7aba-b9e1-46a8-a8b4-87c7384ce140" "path":"/api/v1/projects/00000000-0000-0000-0000-000000000000/measurements" アップストリーム開始 "msg":"Received UpstreamOpenRequest request_id: 2 session_id: 6fd90f07-0dca-47f0-8419-776b995bc876 qos: unreliable ack_interval: 100ms expiry_interval: 1m0s persist: true" "msg":"Succeeded in opening upstream. id=[4f5442cf-74e3-4f98-9695-0f566f5a3127] qos=[unreliable]","tenant_id":0,"message_track_id":"8565-2830-1198","transport_track_id":"4629-1820-3724" 基準時刻受信 "msg":"Received UpstreamMetadata request_id: 4 metadata: *message.BaseTime" 計測開始からここまでが一気に出力されます。 データ伝送 継続中は以下が続きます。 "msg":"MessageCount rx: 0 [msg/sec] tx: 3 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" .. "msg":"MessageCount rx: 1 [msg/sec] tx: 6 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" 計測停止 Motionで計測を停止すると以下が出力されます。 "msg":"Received UpstreamCloseRequest request_id: 8 stream_id: 4f5442cf-74e3-4f98-9695-0f566f5a3127" stream_id は Succeeded in opening upstream. の id と一致しています。 負荷確認 運用でよく確認するサーバー負荷を見てみます。 Motion から以下のデータを5分間ほど送信します。 わかりやすく負荷を上げるために映像データを最大量で送信してみました。 11 映像: H.264 FullHD 30 FPS 8.2 Mbps 音声: PCM IMU GPS 瞬間的に8〜12 Mbps超 AWSコンソール AWSコンソールで推移を確認します。 AWSコンソールの確認 CPUが40%、データ受信が40 MB（≒ 5.5 Mbps）を超えています。 top コマンド top コマンドでメモリの推移を確認します。 top コマンド確認 メモリ使用は 6.5 GBを超えています。 なお、データ格納領域 /data が 98 GB ほど使われています。 df コマンド確認 設定 設定確認 秘匿情報や環境固有情報は、デプロイ資材の .env ファイルからDocker Composer設定ファイルに伝播するようになっています。 例えば、先ほど設定した FQDN は NGINX_SERVER_NAME などに伝播します。 docker-compose.yml 設定変更 では、一部の設定を変更してみましょう。 バックエンド：ログイン試行回数変更 わかりやすい例として Authentication Service の設定を変更します。 Authentication Service user-password attempt-limit : パスワード試行回数のリミット デフォルト値: 5 この回数間違えるとユーザーはロックされます。 正しいパスワードでもログインできなくなります。 ログインするにはロック解除かパスワード再発行が必要です。 Authentication Serviceの項目を持つ docker-compose.api.yml を編集します。 パスワード試行回数のリミットを1回に変更します。 サービス名、セクション名、設定項目をつなげて項目名を AUTH + _ + USER_PASSWORD + _ + ATTEMPT_LIMIT にします。 AUTH_USER_PASSWORD_ATTEMPT_LIMIT : 1 サービス auth を再起動します。 docker compose up -d auth パスワード試行回数の変更・再起動 Admin Consoleでユーザー test を作り、ログインを1度失敗します。 ログイン失敗 intdash ユーザーで test ユーザーを確認すると "ロック中" になっています。 ログイン試行1回失敗でロック中 フロントエンド：ロゴ変更 例外として、フロントエンドはWebデプロイ資材を直接書き換えます。 今回はData Visualizerのロゴを変更してみます。 標準は画面左上に出てくる VISUAL M2M の画像です。 標準ロゴ 以下の設定項目を変更します。 VM2M Data Visualizer（フロントエンド） vm2m-2nd-configの設定 header logoImgURL : Data Visualzierのヘッダロゴ AWS S3に配置・公開した 幅200px、高さ56px のPNGファイルを指定します。 PNGファイルS3配置 cd deployment/ vi docker/ui-conf/vm2m-data-viz-backend/config/vm2m-2nd-config/vm2m-2nd-config.production.json " header ": { " logoImgURL ": " https://s3.ap-northeast-1.amazonaws.com/<S3_BUCKET_NAME>/docker.png " } , vm2m-2nd-configの編集 Data Visualizerサービスを再起動してData Visualizerを表示します。 docker compose restart vm2m-data-viz-backend カスタムロゴ おわりに Dockerで開発用のintdash環境を構築してみました。 普段は意識しないサービスやDB構造を確認することで理解が深まり、 設定やログ、パフォーマンスを見ることで運用イメージがつきました。 設定項目は他にも多くあるので、また別の機会にご紹介できればと思います。 簡易環境の構築方法としては、これまでAWS マーケットプレイスにAMIを提供していました。コンテナイメージとDocker Composeでの仮想化により、AWS以外での構築方法と統合され、バージョン最新化も容易になりました。 ↩ 構築および運用手順はintdashの公式マニュアルをご参照ください。閲覧にはユーザー登録が必要です。 ↩ 冗長構成では各サービスごとにインスタンスが細分化、またスケールアウトします。 ↩ 簡易環境は開発用途の構成であり、本格的な運用には向きません。本番環境向けの構成は Kubernetes または RPM で構築します。 ↩ WindowsではWSLのUbuntu環境などで実行できます。 ↩ 本記事では、基本的に公式マニュアルに沿って進め、各ステップで「どういう目的で何が行われているか」「構築結果をどう確認するか」にフォーカスして解説します。 ↩ 利用するAMI IDはリージョンなどにより異なるため、Rocky Linux公式サイトで最新のものを確認してください。 ↩ ICMPポートは開けていないため、pingは通りません。 ↩ デフォルトではコンテナ内のSMTP（mailコンテナ）を使用していますが、外部SMTP（Gmail等）を利用するように変更します。 ↩ ログはDockerコンテナが再作成されると消えてしまいます。必要に応じて Docker Compose の設定で syslog 等で外部保存します。 ↩ なお、Motion側のWi-Fi帯域を超えており、データ量の86.4 %しか送信できていません。 ↩

こんにちは。 エニグモ採用担当の戸井です。 普段は中途採用や採用広報を担当していますが、主にエンジニア採用を担当している関係で、エンジニア組織の「Developer Relations（DevRel）チーム」にも所属しています。 DevRelチームはエンジニア組織のアウトプット促進や勉強会の運営やイベントサポートなどを行っており、その一環としてアドベントカレンダーの運営にも携わっています。 この記事では昨年実施したアドベントカレンダー全体の振り返りと、運営の取り組みについて紹介します。 アドベントカレンダーとは？ 元々は、クリスマスまでの日数をカウントダウンするために使われるカレンダーで、12月1日からはじまり、25個ある「窓」を毎日1つずつ開けて中に入っている小さなお菓子やプレゼントを楽しむものです。 その慣習から、12月1日から25日まで毎日ブログ記事を公開するイベントとして、特にWeb業界やエンジニア界隈で広く親しまれています。 2025年のエニグモアドベントカレンダーはこちらです。 https://qiita.com/advent-calendar/2025/enigmo 2025年アドベントカレンダー全体の振り返り エニグモのアドベントカレンダーは2018年よりスタートし、2025年で開催8回目となりました。 当初はエンジニア・テック系職種を中心とした取り組みでしたが、2022年からは全社イベントとして、職種問わず誰でも参加できる形で運営しています。 参加メンバーの傾向 2025年も、エンジニアを中心にさまざまな職種のメンバーが参加しました。 （内訳） 【エンジニア職種】 サーバーサイドエンジニア、インフラエンジニア、データエンジニア、検索エンジニア、データサイエンティストなど 【ビジネス職種】 マーケティング、データアナリスト、UI/UXデザイナー、管理部門など 技術系職種を中心としつつも、データ・デザイン・コーポレートなど、複数の部門から参加があり、職種横断でのアウトプットの場となりました。 また、参加回数の観点では、初めて参加するメンバーが全体の約4割を占めていました。 一方で、複数回参加しているメンバーや皆勤賞のメンバーもおり、継続的にアウトプットの場として活用されている点も特徴です。 アドベントカレンダーを一年間の振り返りやナレッジの棚卸しの機会として活用しているメンバーも多いです。 記事のテーマ・カテゴリ 記事のカテゴリーを以下の4つに分類し、集計を行いました。 ・技術発信 ・プロジェクト紹介 ・組織・カルチャー ・入社エントリ・自己紹介 2025年は、技術発信の記事が全体の多くを占めており、エンジニアリングに関する知見の共有が中心となりました。 他にも組織やカルチャー、プロジェクト紹介、入社エントリ・自己紹介といったテーマの記事も投稿されています。 技術に限らず、個人の経験や組織の取り組みなど、多様な切り口での発信が行われたことも特徴です。　 「Advent Calendar Award」受賞記事 「Advent Calendar Award」はエニグモのアドベントカレンダーをさらに盛り上げるために実施しており、特に多く読まれた記事を表彰しています。 2025年の受賞記事は以下の通りです。 6位 アジャイルは会社ごとに別物。でも、あるあるは共通だった （BUYMA TRAVEL Webエンジニア） 5位： ローコードAIツールDifyをエンジニアが使ったら？コードブロックでハマった7つの落とし穴 （データサイエンティスト） 4位： エニグモのオンボーディング：他部署体験プログラムを紹介します！ （採用・採用広報担当） 3位： 人事からデータアナリストへ。社内公募で兼務し始めて3ヶ月の振り返り （人事兼データアナリスト） 2位： AWSにおけるコスト削減の考え方 （インフラエンジニア） 1位： Ruby on Rails アプリのパフォーマンス最適化10選 （バックエンドエンジニア） 運営の取り組み アドベントカレンダーの運営では、キックオフの実施タイミングや日々のリマインド、ガイドライン整備、執筆・レビューの進め方など、運営に関わる各プロセスを毎年アップデートしています。 また、当社のメイン事業である海外ファッションEC「BUYMA」では、年末に向けた大型セールや需要の高まりにより、12月は特にサイトへのアクセスや取引が増える時期です。 それに伴い、エンジニア側でも重要なリリースや対応が重なるタイミングとなります。 そのため、アドベントカレンダーも参加メンバー・運営側の双方にとって、無理なく継続できるよう運営を設計しています。 ここでは、こうした背景を踏まえつつ、今年特に注力した取り組みについて紹介します。 ここ2〜3年で入社したメンバーの中には、アドベントカレンダーへの参加経験がない方や、テックブログ執筆が初めての方も一定数いました。 そのため、「初めてでも参加しやすい状態をつくること」を意識しました。 具体的には、エニグモで初めてテックブログを書く方向けに、記事のテーマの考え方や執筆の進め方を解説するレクチャー会を実施しました。 レクチャー会では、以下のような内容を扱いました。 記事を書く目的の共有 テーマの考え方 記事の構成や書き方 レクチャー会の資料 テーマの考え方を説明した後は、実際に記事を書き進める際の流れについても、画面共有でデモンストレーションを行いました。 テーマ決定から情報整理、構成作成、リード文やタイトル作成までの流れをステップごとに分解し、「どのように記事を組み立てていくのか」をイメージできるようにしています。 また、ワークショップ形式を取り入れ、参加者がチームに分かれてテーマの検討や構成作成に取り組みながら、相談やディスカッションを行う時間を設けました。 ワークの中では、 * どのようなテーマを選んだか * テーマ設定で悩んだポイント * 書こうとしている内容や構成 * 書く中で詰まりそうな点 などを共有しながら進めてもらいました。 最後には全体でテーマや悩みを共有する時間も設け、他のメンバーの視点に触れることで、「自分の経験も記事になる」という実感につながるよう設計しました。 また、全体向けのレクチャーに加え、特に入社間もないメンバーに対しては個別に声がけを行い、テーマ設定や執筆の進め方についてフォローを行いました。 ショートミーティングを実施し、これまでの業務や担当プロジェクトを振り返りながら、その中にある技術的な工夫や、入社直後だからこそ気づけた改善点などをテーマとして言語化するサポートを行いました。 運営を通じた振り返り 今回は、例年の運営フローをベースにしながらも、初めて参加するメンバーへのサポートを強化したことが特徴でした。 その結果、新たに参加したメンバーが増えたことは、運営面でも大きな収穫だったと考えています。 レクチャー会に参加したものの、今回のアドベントカレンダーには参加できなかったメンバーも、「自分の経験でも記事を書けそう」「いつか書いてみたい」と感じるきっかけになっていれば、次回以降の参加につながる土台にはなっていると考えています。 アドベントカレンダーは年に一度の期間限定イベントではありますが、こうした毎年の積み重ねが、継続的なアウトプット文化を広げる大きなきっかけになると感じました。 また、今回の運用を通じて、いくつか改善したいポイントもあります。 まず、公開前のレビューが一部のメンバーに集中する場面がありました。 今後は、レビュー観点を整理したテンプレートの整備や、AIを活用したレビュー支援なども検討し、よりスムーズに進められる体制を整えていきたいと考えています。 また、アドベントカレンダーに限らず、継続的に発信しやすい状態をつくることも重要だと感じています。 そのため現在は、日常的なアウトプットを促進する仕組みづくりにも取り組んでいます。 さいごに 2025年もエニグモのアドベントカレンダーは、無事25日完走することができました。 従来の運営フローをベースにしつつ、初めて執筆するメンバーへのサポートを強化したことで、新しい参加の広がりにもつながりました。 今後も、より継続的に情報発信しやすい運営を目指していきます。 これからのエニグモ開発者ブログの発信を、ぜひご覧いただけると嬉しいです。

この記事は社内のLTで発表したものです。 フロントエンドにおけるドメインモデリングについてあまり記事がないため2つのパートにわけて解説をしました。 今回はフロントエンドとサーバーサイドのドメインの違いにフォーカスして解説しています。 参考文献 WEBフロントエンドにおけるソフトウェア設計の考察 - Speaker Deck 現場で役立つシステム設計の原則 | 技術評論社 エリック・エヴァンスのドメイン駆動設計（Eric Evans 今関 剛 和智 右桂 牧野 祐子 今関 剛）｜翔泳社の本