記事 on Clarence｜Backend・AI・DevOps・Infrastructure

私の技術的な仕事の進め方：Backend、AI、DevOps、Infrastructure

Wed, 08 Jul 2026 00:30:00 +0800

私は Backend、AI、DevOps、Infrastructure、Network を別々の領域としてではなく、実際に動くプロダクトを支えるひとつの delivery chain として扱っています。

機能を使える状態にするには API が安定している必要があります。サービスを更新するには CI/CD が必要です。長期運用するには monitoring、backup、network、security が必要です。LLM、Speech AI、GPU runtime を使う場合も、model integration は deployable、observable、operable でなければなりません。

主に扱う領域

Backend / API

Backend は私の中心的な領域です。API design、service integration、database access、既存システム連携、admin workflow を扱います。Node.js、Python、Go、PHP、C/C++、Shell Script、Java を、既存アーキテクチャや運用性に合わせて使います。

重視しているのは、API が明確であること、data flow を追跡できること、error を診断できること、そして次の担当者が保守できることです。

LLM / Speech AI

2022 年から LLM と Speech AI を実際のプロダクト workflow に組み込んでいます。単に model API を呼ぶだけではなく、prompt、batch processing、local model、GPU runtime、OpenAI API、Ollama、Kaldi、Whisper、既存 backend workflow を接続します。

入力データの整理、出力の検証、retry、cost control、local model と cloud API の選択、runtime environment の再現性を重視します。

GitLab CI/CD 設定ガイド

Tue, 30 Jan 2024 15:00:00 +0800

Enterprise DevOps の実務では、code submission から production deployment までの GitLab CI/CD workflow を構築・運用します。ここではよく使う configuration pattern を整理します。

GitLab Runner

Self-hosted runner は、private network、private registry、特定 runtime environment が必要な場合に便利です。

# Install GitLab Runner
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt-get install gitlab-runner

# Register runner
sudo gitlab-runner register \
  --url "https://gitlab.company.com/" \
  --registration-token "YOUR_TOKEN" \
  --executor "docker" \
  --docker-image "alpine:latest" \
  --description "Production Runner" \
  --tag-list "production,docker"

Docker build を行う場合、runner の security と build requirements を合わせて設計する必要があります。Docker-in-Docker は便利ですが、privileged mode のリスクも理解して使うべきです。

高トラフィック Web Hosting 運用

Sat, 21 Jan 2023 02:00:00 +0800

私は 4000 以上の Web サイトを載せる high-traffic hosting environment を長期運用した経験があります。この種の仕事は Web server を立てるだけではなく、capacity planning、monitoring、updates、security、DNS / CDN、incident response、日常運用の標準化が必要です。

規模が大きくなるほど、設定変更、証明書、更新、alert 対応を人の記憶だけに頼ることはリスクになります。

Cloudflare 30-day Metrics

1 か月の traffic 例：

Requests 約 1900 万
Bandwidth 約 2 TB
Visits 70 万以上
Page views 100 万以上

運用で重視すること

Monitoring は手動確認より先にある

大量サイトの環境では、ページを手で開いて確認するだけでは足りません。System resources、Web server status、certificates、DNS、HTTP response、error rate、traffic trend を monitoring に入れる必要があります。

Monitoring は alert のためだけではなく、問題が application、network、CDN、DNS、storage、upstream service のどこにあるか判断するための材料です。

Updates は controlled に行う

Hosting environment では security update が必要ですが、同時に既存サイトを壊してはいけません。更新は段階的に行い、観測でき、rollback できる状態にする必要があります。