ID:81748さん

# 概要 会社の中核を担うサービスで、月間アクティブユーザー（MAU）約10〜20万人規模の「就活会議 (syukatsu-kaigi.jp)」の、Embedded SREとして従事。 インフラの改善のほか、アプリケーションチームと密に連携し、APIリクエスト増加や5xxエラーの分析を通じた性能・安定性向上、また、サービスメンテナンスを伴うDBのメジャーアップデートなど、クリティカルな運用業務も完遂 # 開発環境 - アプリ：Ruby (Ruby on Rails) / Sidekiq / GraphQL / Elasticsearch / Flutter / Swift - プラットフォーム：AWS - DB系：MySQL (Aurora) / Elastic Cloud / ElastiCache (Redis) - モニタリング：Datadog / CloudWatch / Better Uptime / Airbrake - CI/CD：GitHub Actions - メール：SendGrid / SES - マーケ分析：BigQuery / Redash / HubSpot / Repro - AI系：Github Copilot / Devin # 業務内容 1. SRE（監視・信頼性改善） - Datadog APMを用いてアプリケーションのレイテンシを可視化し、ボトルネックの特定・改善を推進 - レイテンシ急上昇やエラー率増加などクリティカル指標に対する監視・通知を整備し、早期検知体制を強化 - CUJ（Critical User Journey）に基づくSLO/SLI エラーバジェットの策定 - Aurora、Redis、Elastic Cloud 等の各種DB・ミドルウェアのメジャーアップデート 2. ユーザー分析基盤 - BigQueryのデータ取り込み基盤（Datastream / DTS など）の設計・構築 - HubSpot / Repro 由来の顧客分析データをBigQueryへ取り込むためのデータパイプラインを整備 3. セキュリティ対策 - WAF および Datadog の保護機能を活用し、アプリケーションセキュリティ対策を実施 - SQLインジェクション等の攻撃ログを分析し、アクセス元の自動遮断（ブロック）を含む対策を実装 4. コスト最適化 - ECS on Fargateのスケーリング方針を見直し、CPU/Memoryのリソース最適化を実施 - Cost Explorer等を用いて高額リソース（RDS等）のコスト増加要因を分析 - RDSスナップショット運用を見直し、ダンプデータのS3保存への移行によりコスト最小化を推進 # プロジェクトの振り返り - 課題と成果 ユーザーが安心安全に利用できる信頼性の高いサイトを目指して様々なことに着手していました。 当初、頻発するサイバー攻撃により、大量のリクエストに伴う5xxエラーの発生やElasticsearchのレスポンス遅延など、サービスの可用性に重大な影響が出ていました。これに対し、WAFやDatadog Application Securityを活用した攻撃ログの分析を徹底し、不正アクセスの自動ブロック機能を実装。攻撃被害を大幅に低減し、インフラの堅牢性を高めることができました。 - 反省と再発防止 一方で、セキュリティを強化し自動化を推進した結果、本来許可すべきSEOクローラー等の正常なBotまで誤ブロックしてしまい、検索順位（SEO評価）に影響を及ぼすという事象を招きました。自動化に頼りすぎたことで目視による確認プロセスが形骸化し、誤検知の予兆を見逃したことが原因でした。 - 改善点について - モニタリングの強化 攻撃ブロック数だけでなく、正常なトラフィックの減少やクローラーの挙動を監視するダッシュボードを整備し、誤検知を早期に検知できる体制を構築 - 継続的なチューニング インフラやセキュリティ設定に「完成」はなく、常に最新のトラフィック状況に合わせて設定をアップデートし続ける運用の重要性を痛感しました。 現在は「セキュリティと利便性のトレードオフ」を常に意識し、100%の安全を過信せず、予期せぬ影響を最小化するためのオブザーバビリティの向上に努めています。

# 概要 全社で運営する十数種類の多種多様なサービス（中〜小規模）に対し、横断的にインフラ管理・自動化を支援 # 使用技術 プラットフォーム: AWS, Google Cloud, Cloudflare コンテナ: ECS, EKS (Auto Mode) IaC: Terraform, Terragrunt, ecspresso, Helm 監視: Datadog, Grafana, CloudWatch, Sentry CI/CD: GitHub Actions, CodeBuild, CodeDeploy, ArgoCD 言語：Rails / React.js / NestJS / Remix / TypeScript / Go / bash # 業務内容 1. ECS / EKS のインフラ各種改善 - オートスケーリングの設計・整備（ECS Auto Scaling / Kubernetes HPA） - 可用性担保のための運用設計（Kubernetes PDB 等の導入・調整） - リリースフローの整備・自動化（- GitHub Actions や ArgoCD を用いた GitOpsフロー整備） - サービス要件に応じた実行基盤の移行・運用（Fargate から EKS Auto Mode への移行・管理） 2. IaC（Infrastructure as Code）の標準化と保守性改善 - Terraform、Terragrunt、ecspressoを活用したコード管理 - Terraform Module化による構成の共通化を推進し、新規プロジェクトの立ち上げ工数削減と品質の均一化 - bash や Go 言語 を使ったインフラ自動化スクリプトの作成 3. Datadogを中心としたオブザーバビリティ・運用 - Datadog（APM/DBM/Synthetics）の導入による多角的なモニタリング体制の構築 - SLI/SLOの策定・運用において、プロダクト・マーケ各部門との合意形成を主導 - ログ保存容量の調整や契約コミット量の最適化によるDatadog利用コストの適正化 4. セキュリティ対策・ガバナンスの強化 - 「最小権限の原則」に基づくIAM権限の全面的な見直し - IAM Access Analyzerを用いた未使用権限の定期的な棚卸し - Security Hub / Macie / Inspector を活用した機密情報の検知 # こだわった点と振り返り - コンテナ環境の最適化 こだわった部分としては、コンテナ環境のリソース最大化とコスト最適化。 コンテナ環境は ECS / EKS が中心であり、Fargate Scaling や Kubernetes の HPA や PDB を取り得れたスケーリング・キャパシティ戦略を打ち出したり、 適切なパフォーマンスとコストのバランス収束させるため、CPU と Memory の最適化を図った。 - IaCの保守性と再利用性の向上 ECS プロジェクトは、Terragrunt や ecsoresso を利用した OSS の Iac 管理ツール、EKS プロジェクトは Helm や Kustomization を利用し、リポジトリのテンプレートファイルの可読性、再利用性を高めることを推進しました。 - 学びについて 従来のインフラ・サーバーエンジニアからクラウド・SRE職への転換期であり、当初はクラウドネイティブな技術スタックや文化のキャッチアップに苦慮しました。それでも公式ドキュメントの精読など粘り強くキャッチアップを重ね、技術習得しました。 また、SREチーム内（6名）での相互コードレビューを徹底しました。自身の知見を共有するだけでなく、他メンバーの設計思想を吸収することで、チーム全体でインフラの品質を高めていく協調的なエンジニアリングの重要性を学びました。

# 概要 TA共通基盤システムの構築 大手プレイガイド各社がチケット販売業務で共同で利用する基盤構築 # 使用技術 AWS, CloudFormation, PostgreSQL # 期間・規模 2022年10月~2023年1月 アプリケーション開発、サーバー・インフラ担当などのチームに別れており、全体で100名以上の規模 # 担当業務 - CloudFormation による IaC管理 - Transit Gateway による prod, stg, DR, test の 4環境の管理 - CodePipeline , CodeBuild, CodeDeploy によるリリースプロセスの管理

# 概要 クレジットカード決済システムの基盤刷新に伴い、物理サーバー（Oracle）からVMWare上の仮想環境およびKubernetes（Rancher管理）への移行プロジェクトに従事 高可用性と高パフォーマンスが要求される金融系システムにおいて、コンテナ基盤の構築と、性能の限界を見極めるための詳細な負荷試験・チューニングを担当 # 期間・規模 2022年7月～2022年9月 プロジェクト全体で100~200名の規模 アプリケーション開発、サーバー、ネットワーク構築、運用、セキュリティ、DB、リリーサー、監視チームなど # 使用技術 - プラットフォーム: VMWare, Kubernetes v1.19.15, Rancher - OS/ミドルウェア: RedHat 8.2, Docker, Payara (Java EE) - 監視・CI/CD: Prometheus, Grafana, Zabbix, Jenkins # 担当業務 - VMWare 基盤とした仮想サーバー構築とそれを基盤とした Kuberntes によるコンテナ化 - 基盤、監視、負荷テスト、ロングランテストの実施 - Prometheus と Grafana による Pod モニタリング 監視や性能チューニング # 取り組みやこだわった点 - 負荷テストと性能チューニング試験 レプリカセットでPod数1に設定し、負荷量に関わらずスケーリングしない状態のまま、1台のPodで耐えうるスペックを定める VMはZabbixでモニタリング、コンテナはPrometheusサーバからのCPUやメモリのリソースデータを取得後にGrafanaでモニタリングし、 適正スペックかをインフラチーム内で検討を行い、チューニングと試験を繰り返しながら必要スペックを定めていった 以下の観点 - Javaヒープメモリの最大値が適正か（OutofMemoryが発生しないこと） - スレッドの最大値が適正か（一部リクエストだけ性能劣化することがない） - DBコネクション数の最大値が適正か（Connection不足によるエラーが発生しない、一部リクエストだけ性能劣化しない） - ロングランテストでメモリリークが発生していないか、途中で性能劣化していないか（GCが発生しているタイミングなど）、フルGCが何秒も発生していないか # 反省点 この案件は「モニタリング」「負荷試験とチューニング」というインフラエンジニアとして最重要とも言える業務がメインでした。 技術環境が非常にハイレベルで当時の私の技術と比較して大きなギャップがあり、苦戦をしいられましたが、大きな経験となりました。 コンテナのモニタリングにおいて、Podのメモリなのかクラスター全体でのメモリなのかを見誤りそうになり、コンテナ技術の理解度が不足していたり、至らない部分は多くありました。 3ヶ月と短い期間でも学べたことは多くあり、その後のクラウドネイティブな環境でのSRE業務にも活かされています。

# 概要 電力の計量計算を行う業務システムのインフラ構築 # 期間と規模 2021年7月~2022年6月 インフラチーム3名 # 使用技術 Java, JBoss, Wildfly, PostgreSQL, OpenVPN, AWS # 担当業務 電力計算の業務アプリケーションのインフラ設計構築 - EC2, ALB, RDS(PostgreSQL), Route53, S3, Lambda, WAF などリソース構築 - CloudFormationで本番環境と災対環境の管理 - CloudWatchやKinesisなどを利用してDBの死活監視、ログ監視の構築 # 担当業務 ・EC2,RDS(PostgreSQL),Route53,S3などリソース構築 ・CloudFormationで本番環境と災対環境のインフラをコーディング ・CloudWatchやKinesisなどを利用してDBの死活監視、ログ監視の構築 ・Lambda関数を使ったバッチ処理(Python)、ALBやRDSとの関連付け ・WAFやALBの構築 ・ClientVPN接続の際の証明書作成やACMで証明書管理 # 取り組みやこだわった点 1. S3のストレージ設計 ・バケットごとにアクセス制限を設けるバケットポリシーを採用し、S3パブ　リックアクセスブロックを有効にすることで不正アクセスからデータを保護する安心安全なストレージ設計を行い構築 ・運用時間外に画面に表示するHTML(SorryPage)を格納し、運用時間外にアクセスされた場合に出力する設計と構築を行った ・CloudWatchのメトリクスと連携し、OSログ、APログ、DBログ、証跡ログ等を一定期間分保管できるよう、監視設計と監視ログ保存の仕組みを構築した ・RDSのスナップショット機能により取得されたDBのバックアップを保管させること 2. CloudFormaitonによる運用 ・CloudFormationにおける運用においては、拡張性のしやすさと障害発生時のリストア方法の簡略化に注力 ・EC2やRDSにおいてはサーバの処理や利用者増加により、CPU、メモリのリソースが不足する場合はインスタンスのアップグレードを行い、Lambda用リソースジョブの処理件数の増加などによりリソースが不足する場合、追加割り当てを行う運用方針にした CloudFormationによるIaC化においてはコードの可読性を担保しつつ、AZ障害発生時を見据えたバックアップからのリストア作業と復旧時の切り戻し作業をスムーズに行える運用を目指した ・具体的には、Formationのスタックを流す際のパラメータ選択において、インスタンスのスペックやAZ-aとAZ-cをCondition別に分けてパターン別にリソースを構築をできるようにしたりと、柔軟にリストアできるよう手順書に明記・作成し、顧客に納品を行うことができた