ID:12512さん

## 概要 新卒配属でAmebaの基幹システム部に配属。 いくつかの基盤システムの運用・保守・エンハンス開発を担当。 - 外部向けAmebaAPIシステム - ↑のAmebaAPIを利用するためのOAuthシステム - 複数のブラウザサービスでCookie値を同期させるシステム - ユーザのテキスト投稿を監視するシステム - アメンバー管理システム - ↑をはじめとしたつながり情報管理システム（AmebaPlatform） ## 規模 サーバ台数：各システム本番環境で10台〜20台前後 スループット：AmebaAPIは1億APIリクエスト/日 など ## 運用内容 割と安定運用の状態であったため、下記にも記載している自動テストの導入や監視システムリプレースを自発的に行っていた。 ### API追加開発 - 主にAmebaアプリが新規で欲しい機能について依頼が来るので追加開発 - 1APIにつき本番リリースまでおおよそ5営業日 ### エラー・障害対応 - 5xxエラーの対応・予防 - ただの中継APIのため、担当サーバ自体が障害を起こすことは少なかった ### 自動テスト（JUnit）導入 - ユニットテストすらないプロダクトだったため、UtilityクラスからJUnitでテスト化を開始 - 依存先APIやOAuth認証情報を呼ぶメソッドの実装をSpringFrameworkのMethod Injectionで上書きできる術を発見し、各レイヤの依存度の減らしつつ結合テストの記述を推進 - 依存先APIのひとつがHTTPではなく（今は亡き）kumofsの分散技術を流用したものがあり、ベータ導入のCircleCIエンタープライズに乗り換えるときにAWS → 社内オンプレPrivate Subnetへと通信が走るため非常に苦心した ### デイリー集計スクリプトの簡素化 - APIを追加開発するたびに変更が必要であったBashスクリプトの運用をRubyで極小化した。 - むしろ元のBashスクリプトよく誰も文句言わずに運用していたなぁと - Rubyのメタプログラミングで脳汁垂らしまくっててハイになってた - 今思えば、負荷状況確認のためにインフラが導入したfluentdを間借りすればよかった ### 監視サーバリプレース（mon, nagios -> Sensu, InfluxDB, Grafana） - 当時微妙に話題になった＆自身の勉強のためにSensuの環境構築・導入を実施 - Sensuは死活監視かつInfluxDB ＆ Grafanaへのメトリック送信に利用 - InfluxDB & Grafanaはリソース監視としてグラフを作成 ### Chefによる自動プロビジョニング化 - サーバの構築を社内ドキュメントにある秘伝のスクリプトからChefに変更 - 新卒研修時代にChefを知り、「これがサーバ構築の未来だ」って言っていた覚えがある - データセンター移設も相まって、かなり乗り気にChef化を推進 - ステージング・本番環境共にChef乗り換え完了 - とは言いつつも、recipeをhost名で分けるというバッドノウハウを踏み、転職後気づく ### 新規システムへのマイグレーション 監視システムが並列可動している状態で、退職を決めた直後に新監視システムへの統合を決意。 旧システムを利用している各所に協力してもらい、向き先変更の開発に協力。結果、退職直前に無事旧システムのクローズが完了。 ## 課題・障害等 - 慢性的に発生していた5xxエラー数を可能な限り減らすため、エラーの内容・依存先APIサーバの侵入＆ログ確認・問題共有＆箇所指摘等を担当チームと連携を取りつつ（？）対応 - そもそも引き継ぎされた時点で安全なデプロイができないシステムだったため、インフラチームに知見を求めつつデプロイ時にエラーが発生しないような仕組みに変更 ## 脱退時状況 - 担当開始後、1年後に後輩の新卒が参画したため、API追加開発タスクは後輩に託し、サポートに従事。 - モジュール依存度の最小化を果たせぬまま退職したので若干心残り ## その他所感等 - RESTをわかっていないおじさんが `POST /getDetrails` というHTTP APIを実装してきたので文句を言ったのはいい思い出

## 概要 Gunosyにてインフラストラクチャチームに配属、後にSREチームに改名。 「グノシー」および広告配信システムのインフラ面での運用・障害対応・運用改善に従事 ## 規模 本番環境サーバ台数合計400台以上 ピーク時 10,000req/s 以上 ## 運用内容 - Infrastructure as Codeの実践 - 障害対応・恒久対応・障害報告書レビュー - サーバ移設・リプレースのサポート（過去3度ほど） - コスト効率化 - クラウド事業者や外部ベンダーとの渉外交渉や請求書処理など ### codenize.tools の導入 https://codenize.tools/ こちらで提供されている各ツールを導入。 導入後、プロダクト開発担当の人にもわかりやすくコードを編集してもらうために、テンプレート周りの小売化に尽力。 （https://tech.gunosy.io/entry/2018/12/03/173259 こちらのブログ参照） ### Terraform の導入 Gunosyでは、プロダクト単位でAWSアカウントを分割しているが、新規事業（≒新規プロダクト開発）のたびに実施するVPCの初期設定等の構築をTerraform化（tfstateは管理せずに破棄する）した。 ※ Terraformは個人的にあまり好きではないが、現状これ以外の選択肢が少ないため、利用中。好きではない理由は学習コストと記述済みのTerraformコードの見難さ Gunosy退職後に ### ステージング環境構築（あわせて本番環境の野良サーバをプロビジョニング管理下へ） 入社後1年ほど、ある根幹事業のシステムのステージング環境が存在しなかった。 1年動けなかった理由としては - 現本番環境と同等のものを再現することが不可能だった - 声の大きいエンジニアが「この状況を正すには1年ぐらいサービス停止すべき」という非現実な正論を連呼していた。 特に後者が大きい要素だったが、その人が退職（同時に中核メンバーが数名抜けた）してからは、プロダクトの追加開発の頻度を大きく落とさざるを得ず、それによって生まれた時間でステージング環境をプロビジョニング配下に置くため、構築を開始。 他チームメンバーが実行した古のユニットテストで記載されてしまっていたTearDownでステージングDBがふっとばされるという事件もありつつ、3ヶ月ほどでまともに動くステージング環境が構築。その後本番環境のサーバも移設した。 ### 記事検索システム構築・運用・障害対応 配信済みニュース記事をアプリ内で検索する機能を追加するために、Elasticsearchのクラスタ構築。 masterサーバ群・dataサーバ群・client＆ingestサーバ群に分け、X-Packを利用したモニタリングシステムも構築。 会社のプロビジョニング方法として主流だったAWS OpsWorksを利用して構築した。この構築経験はメチャクチャよくてコンテナ全盛期の2021年ですらElasticsearchクラスタ構築にはOpsWorks使いたいと思っている。 構築当初からアクセス負荷がきつかったので、INDEXやシャードのチューニングの実施、障害調査のためのnginxをclientサーバ群に導入した。 たまーーーーにESクラスタのdataノードでCPU使用率100%にハネる事象があったので、アクセスログ（POSTのときのbodyも見れるようにした）から、「******」みたいなワイルドカード連続文字列をESにそのまま投げちゃうのが原因だったので、サーバサイド側で対応してもらった。 Gunosyが提供しているアプリのニュース記事検索は「(勤務地) ランチ」とかで検索すると有益なランチ情報がゴロゴロ出てくるので使ってほしいです。 ### 広告システムのリプレースサポート Python製の広告システムをGo製のシステムにリプレースする案件に従事した。（アプリケーションコードの変更には直接従事はしていない） その際に、インフラ周りの構築やプロビジョニング設定、監視設定、実際の切り替え作業等を担当。 ### インフラリージョン移設 あるシステムが、入社当初から何故かAWS東京リージョン外で可動しており、東京リージョンで稼働している広告システムとの連携の兼ね合いでパフォーマンスボトルネック・技術的負債となっていた。 そのため、大半のシステムを深夜メンテナンスによって移設することを取り決め、担当部署との調整および作業手順等の文章化など、メンテナンスの音頭取りを実施。 事前準備がしっかりできていたおかげで、予定よりも早く問題も発生せずに完了。そのまま深夜メンテ担当者全員と築地市場にいって朝の寿司を嗜んだ。 ### 広告システム アカウント移設 入社するまえから長きに渡ってニュースアプリと広告システムが同一AWSアカウントに同居していた。 ただ、組織が大きくなり担当者が増えるに連れ、設定変更の作業が煩雑（片方の設定変更がもう片方に影響しないかを常に考える必要があった）だったのと、システム毎にインフラコストを算出する作業が煩雑だったため、AWSアカウント移設を打診した。なんとか受理してもらえたので半年ほどかけて移設作業を実施した。 移設にあたり、既存のグッチャグチャの命名規則を統一化すべく、命名規則のルール制定に大きな時間をかけた結果、SREが不在でも設定変更コードレビューがまわるようになった。 あのときの命名規則ルールは会社ブログにでも書いておけばよかった。今すごいほしい。 ### 共通Proxyサーバ構築 会社が提供しているサービスの大半が、「許可してもらった協力先のメディアに対してクローリングし、いただいたデータをサービスの二次提供として利用している」というもので、サービスが増えていくたびにクローラーが増えていくに運用になっていた。 この背景下で「IPアドレスを制限しているメディア」も存在しているため、「会社の事業が新規に立ち上がると、IP制限しているメディアにIP制限緩和のお願いを出す必要がある」という状況に陥っていた。 これ以上増やすことはできないと判断し、リリースされたばかりのAWS PrivateLinkを利用してクロスアカウント間で利用できるSquid Proxyサーバを構築・運用をした。 最大20個ぐらいIPアドレスを許可してもらっていたが、最終的に6つ程度にまで収まったうえIPアドレス更新の作業をなくすことができた。

## 概要 数多くの技術的負債が山積しているトレタにて、整理整頓を中心に実施した。 当時の採用技術スタックは以下の通り。 - アプリケーション言語：Ruby (Ruby on Rails) - サーバ：EC2 - データストア：MySQL, Redis, memcache(いずれもElasticache), S3 - プロビジョニング：Packer(ansible) - 構成管理：Terraform （一部EKSが採用されていたが、作業にほとんど関わってない） - 監視：mackerelとdatadog併用 ### Terraformリファクタ Terraformの運用状態がかなり悲惨だったので、いろいろ整備した。 インフラの運用でBlueGreenデプロイメントが採用されていたが、切り替えるのに毎回Terraformのコードを数百行コメントアウトする/コメントアウトを外すというクソ辛い運用だったのでcount使ったりハードコードされている箇所をdata参照するようにしたりして、変更コストはもちろんのことレビューコストを減らした。 また、入社当初はすべてのTerraformコードが1リポジトリで管理されていたが、CI/CDのときにライフサイクルが異なるものはTerraformリポジトリを分けたほうが運用が楽なのでは、という考えのもとネットワーク設定やシステムごとにTerraformリポジトリを分けたことで運用がかなり楽になった。 ### 掃除 ステージング環境に個人の検証環境がまざっていて、本番環境との同一性を全く担保できない状態だったので、不要なリソースを徹底的に削除した。 とりあえず入社初期は「Route53に紐づくドメインからシステムを理解していこう」と思っていたが、すでに撤退されて存在しないシステムがいたり所在が不明なIPアドレスがAレコードに残っていたりして大変な目にあった。 S3バケットのアクセスログを自分自身のS3バケットに出力するように設定されているせいで、1度S3バケットにアクセスすると無尽蔵にファイルが作成される設定とかもあった。 ### 環境浄化 - IAM固定鍵がハードコードされていたのでEC2インスタンスプロファイルを使うように変更（アプリケーションの改修も担当）。ステージング環境のIAM鍵が本番環境で利用されてたりしていてメチャクチャ辛かった - SSL証明書をすべてACMのDV証明書に変更 - nginxで構築されていたforward proxyサーバ（運用激辛）をSquidサーバにリプレース（アプリケーションの改修も担当） ### SPAサイトのサーバレス化 フロントエンドのJavascriptを配信するためだけのEC2サーバが生き残っていたので、S3+CloudFront化を提言し作業着手。 切り替え前構築作業中はJS特有のHash APIによるリダイレクトの問題が発生し（たしか）CloudFrontのPath patternでなんとか乗り切り、切り替え後にブラウザキャッシュ問題が発生しs-maxageヘッダを利用することで解消。 JS配信サーバのB/G環境もろとも削除してインフラがなくなった。 ### AWS SSO導入 詳細こちら https://tech.toreta.in/entry/2019/12/16/154024 ### ### gRPCサーバのインフラ構築 システムリプレース案件で、これまで利用していた

## 概要 LegalForce製品のインフラ面での開発・運用保守を担当した。 一時期はLegalForceキャビネも見ていたため、一部GCPでも作業を実施した。 日々の作業としてはボトムアップで課題提起した改善タスクを粛々と実施している。 - アプリケーション言語：Ruby、Python - サーバ：ECS、GKE - データストア：MySQL、Elasticsearch(v7) - AWSサービス： ECS、S3、SSO、IAM - GCPサービス：GKE - デプロイメント：CircleCI, GitHub Actions - 監視：Datadog、CloudWatch、Sentry - 構成管理：Terraform - 社員DB：AzureAD ### 社内向けシステムのSSOログインのためのAzureAD初期構築 入社直後、社内向けシステムがOIDCを認証方法として開発が進んでいたが、IdPの整備が進んでいなかったため情シスの代わりとして導入をすすめた。 社内向けシステムは社内広範囲に渡ってログインできる必要があるため、おのずとIdPも全社導入することになりそうだった。 当時はOneLoginに片手を出している状態だったが、全社導入には程遠い状態でかつオーナーシップが不在で全く進む気配がなかったので、自分が選定・初期の導入を実施した。 IdPは以下の3点で比較した。 - OneLogin：以前の職場で触ったことがあるので経験を活かせる - Okta：未知数だが機能は多そう - AzureAD：Office365導入済みのために全社導入は容易と想定 OneLoginは代理店との連絡の遅さ（ユーザ数追加の申請→対応まで致命的に時間がかかる）を懸念し、OktaはコストネックのためAzureADに決定し、社内システムとのつなぎこみを実施した。具体的には以下の作業をした。 - AzureADのグループ設計 - AzureADのアプリケーション・エンタープライズアプリケーションの作成 - OIDC用パラメータ払い出しとつなぎこみ動作確認 - AzureADのグループと社員ユーザの関連付けコード管理化のためにTerraform導入（情シスにAzureAD担当者が入ったタイミングで廃止） - 引き継ぎ用ドキュメント作成 後に情シスにAzureAD担当が入社したタイミングで引き継ぎを完了させ、AzureADからは手を引いた。 OIDCの払い出しの異常な複雑さや、セッショントークン延長の作業難易度が非常に高いので、AzureADでOIDC連携するのは全くオススメできない、という経験を得た。 ### AWS SSO導入 ＆ Terraform化 ### EKS導入検証 (WIP) ### AWSアカウントの環境ステージごとの分割 (WIP) ### Terraformリポジトリリファクタ & CI/CD化 (WIP) ### 新規事業 ### その他 - TV CM対応 - ISMS対応 - Techリードとしてメンバーとの1on1対応 など