@_y_ohgi の履歴書兼職務経歴書です。
| Site | Link |
|---|---|
| @_y_ohgi | |
| ogi.yusuke | |
| GitHub | y-ohgi |
| Blog | y-ohgi's blog |
| Speaker Deck | y-ohgi (@y0hgi) |
※ Twitterがレス早いです。
現在は"SRE as a Service"という、他社様との伴走型のSRE支援をさせていただいております。
【入社エントリ】株式会社Topotalに入社して3ヶ月が経ちました - y-ohgi's blog
フルタイムでSRE としてして働かせていただいたり、技術顧問としてお手伝いさせていただいたり、スタートアップの立ち上げなどに携わらせていただいております。
AWS/Google Cloudのクラウドインフラエンジニアとしてが半分、フルスタックとして携わらせていただくのが半分ほどでした。
NDAの問題で直接記載することが難しいため、直接聞いて頂けると幸いです。
使用した技術スタックは以下になります。
TypeScript, Next.js, Golang, GKE, ECS, Cloud Run, Terraform, CDK, etc...
現在も個人事業主として副業を受け付けております。
シチュエーションボイスという音声作品のCtoCサービスを作成していました。
個人開発の一貫として行っていたのですが、想像以上に規模が大きくなったことと特商法のために会社の立ち上げを行いました。
クリエイターさんが使い勝手を試すための2回のクローズドベータテストを行いサービスを納得の行くクオリティで完成させることができました。
2回目のクローズドベータテストの規模としては最終的に100人のクリエイターさんに集まってもらうことができました。
しかし開発費を自己資金で補っており、損益分岐点を考えたときにショートすることが明確だったため、リリースを断念しました。
サービスの開発には開発は私一人、デザイナーさんや広報の方など8人の方に開発を手伝っていただくことができました。
その中で会社の立ち上げからリリース失敗まで、ひとつのサービスをリリースするための数字やノウハウの一端を見ることができました。
リリース自体は失敗してしまいましたが、Discordでクリエイターさんの意見を伺いながら開発するというユーザーの声を一番近くで聞くという貴重な経験を得られました。
所属していたSREチームがSRE"部"になると同時にCTO室へ転属しました。
モチベーションとしては社内へ「クラウドインフラの知見を広めたいこと」にあります。
また、SRE部になる際に方針が変わり、自身の求めていたSREとは変わってしまったこともあります。
CTO室では技術支援を行い、AWSやGCPやオンプレなど複数プロダクトのアーキテクチャレビューを主に行っています。
社の技術水準向上を目的にクラウドに関係する勉強会やPodcast・LT会の主催を継続的に行ったり、アーキテクチャレビューの他にスクラムマスターも兼任もしています。
主にクラウドという技術をネタに、社の全ての技術水準向上に貢献できるよう努めています。
「決済ログサービスのリプレイス」プロジェクトからCTO室へ転属しました。
CTO室では社内のクラウドインフラを推進し、全社的にクラウドインフラの技術力向上をミッションとしていました。
実際にプロダクトに入り、問題点の洗い出しと一緒に解決する（Dockerの導入やAWSアーキテクチャの見直しと改修、全社AWSコストの削減など）を行い、全社の「クラウドインフラの技術力向上」に努めました。
その他にも勉強会をいくつか開催するなど、社内のクラウドインフラコミュニティをゆるく立ち上げ、そのコミュニティ内で勉強会/LT会/Podcastなど、カジュアルに技術供する場所ができたと思っています。
その後、2018年の秋頃に組織再編でSREチームが発起し、私はCTO室と兼任でSREの立ち上げに関わりはじめました。
SREのミッションとしては「全社的にサイトの信頼性」を高めることで、現在はそのためのアーキテクチャの設計・開発・見直しを実際にプロダクト開発に関わりながら行っております。
具体的なタスクとしては負債脱却やサービスの運用など多岐にわたりますが、いまいまの初期フェーズとして、「AWS利用時のフレームワーク」の策定と運用を行っています。
SREとしてサイトの信頼性を高めるために運用から入るのではなく、開発フェーズからSREが障害の起きにくい・障害から回復しやすいアーキテクチャの設計/開発を行うことが目的です。
このフレームワークはSREチームが関わっているプロダクションでのノウハウをもとにベストプラクティスを（コードやドキュメントへ）ブラッシュアップしながら反映するようなものになります。
このフレームワークを導入した結果、新規開発で車輪の再開発を行わずに、SREが定義したベストプラクティスにのっとることで迅速にAWS環境を手に入れることができるようになりました。
また、このフレームワークを社内に広めるために、勉強会も活発に主催してフレームワークで取り扱われているDocker/AWS/Terraform/Datadogなどのコンポーネントについて、実際にプロダクションで使用する際のノウハウ共有を主導して行っています。
まだ立ち上げから1年経っていませんが、得た経験として技術力はもちろん、特にコミュニケーション面での学びがありました。
人へのものの伝え方やMTGの行い方、モチベーションを維持させる方法など、単純にエンジニアリングをやっていただけでは得られない経験が多かったと思っております。
また、国内有数のマイクロサービス化されているプロダクトでSREとしてアーキテクチャを俯瞰して学べるのは同じく自分の経験値として大きなものが得られていると感じています。
PostgreSQL, Kubernetes, GCP, GAE, CircleCI, GitHub:Enterprise, GKE, Spanner
決済ログサービスのリプレイスへGCPインフラの担当として携わりました。
決済系処理がマイクロサービス化されており、そのうちの1サービスである決済ログサービスのリプレイスに携わりました。
決済ログサービスは "決済が行われた際の情報" を扱うAPIを提供し、購入履歴や返金・BIなど、社内のサービスの決済情報を一箇所に集める非常に重要なサービスになります。
また、社内ではゲーム・EC・動画・英会話などtoC/toB問わず複数のサービスを扱っており、昼夜問わず決済リクエストがあるため高い可用性が求められました。
また、依存する小さなサービスがあと2つ存在し、計3つのサービスで構成されています。
技術的な話になりますが、マイクロサービスを意識したわけではなく、責務が異なるためモノリスにすることを避けました。
技術面では社内で初めてGCPを採用するというチャレンジを行いました。
理由としては以下の3つになります。
SLAが非常に高くメンテナンスウィンドウのない "Cloud Spanner" を採用する。
GAE/SE のようなマネージドサービスで運用コストを下げる。
社内でのデファクトスタンダードがAWSになりつつあるため、GCPの採用事例と知見を社内へ取り入れるため。
言語面では "Kotlin" x "Spring Boot" を採用しました。
Kotlinを採用した理由としては、チームで得意な言語がScalaだったのですが部署内ではJavaがデファクトスタンダードとなっており、今後運用を別チームに任せる可能性があったためJavaとScalaの中間であるKotlinを採用しました。
SpringBootを採用した理由としては使用できるエンジニアが多いことが理由です。
しかし結果的にレイヤードアーキテクチャと関数型のアプローチ（主にDI）を取り入れることでフレームワークを用いている箇所はパスのルーティングのみとなっています。
私は今年の3月に参加しました。 この時点では当該サービスの開発が半分ほど完了しており、納期が6月といった状況でした。
担当領域としてはスクラム開発を取り入れていたためアプリやインフラのみといった特定の領域を担当するわけではなく、フルスタックなエンジニアとして参加しました。
しかし、参加した当初のインフラの状況は開発環境すら存在しない状況で、各サービスの動作確認だけが終わっているといった状況だったためインフラ専任として担当させていただきました。
私自身にGCPの開発経験がなく、初めてGCPへ触るため技術的な難しさと面白さを感じながら試行錯誤する日々でした。
複数の課題が残っていましたが、負荷試験の実施・CI/CD環境・監視などサービスの運用に必要なことを開発でき、価値の高いものを生み出せたと感じています。
Scala, Ruby, Node.js, lambda, docker-compose, Docker, CloudFormation, AWS, ECS
新卒で入社し、最初に配属されたプロジェクトです。
社内API Gateway（マイクロサービスパターンの認証認可サービスでKongやapigeeの社内版。）のリプレイスプロジェクトで、ScalaとAWSのプロジェクトになります。
フルマネージドサービスやOSSのAPI Gatewayを用いず、自社開発する理由としては既存のAPI Gatewayの独自仕様を組み込む必要があり、そのコストを加味したところ自社開発のメリットが高くなったためです。
このプロジェクトではAWSを担当させていただきました。
既に1人AWSを担当している先輩がおり、私がジョインした時点で既にアプリケーション側は完成しており、インフラ側は設計とアプリケーションを動かすだけの最低構成が完了していました。
担当した領域としてはアプリケーション以外のロギングや、CloudFormationのコーディングです。
社内で初めて運用される本番のコンテナオーケストレーションということで社内に知見がなく、ここで一番苦労を強いられました。ですが、新しい試みということで非常に挑戦し甲斐がありました。
設計済みの構成を検証とCloudFormationへのコーディングを行うことがメインでしたが特に手応えを感じているのは以下の2つです。
1つ目は既に記述が完了しているCloudFormationのテンプレートを改めて読み直し、仕様漏れの対応を行った点です。純粋にAWSサービスの設定を把握しきれておらず設定漏れをしていた点の修正だけでなく、社内マイクロサービスと既存のAPI Gatewayの仕様が合わさりアプリケーション側の仕様がインフラ側へも波及している点（主に課金APIの仕様でHTTPレスポンスが最大140秒かかるAPI）への対応を行いました。対応内容としては主にドレイニングの仕組みを導入しました。ALBとECSのコンフィグの修正、Lambdaを用いたグレイスフルなドレイニングの仕組みを導入。また、インフラだけでなくアプリケーション側のコンフィグへも修正を行いました。
2つ目は今後CloudFormationを運用際に現在のテンプレートの書き方では運用が厳しくなるためその書き直しを行った点です。ネステッドスタック構成になっていたため、ネステッドスタック構成の解除を行い、それぞれのテンプレートを適切な粒度に落とし込みました。
このプロジェクトでは配属された当時は社員が2人居たのですが、私の配属後4ヶ月目にAWSの担当者が、5ヶ月目にアプリケーションエンジニアが抜けてしまい、私1人になってしまいました（プロジェクトに問題があったというより、タイミングがよく(？)重なり2人とも抜けてしまった形になります）。
そのため頼れる方が居なくなり、改めてプロジェクトについて考え、タスクの洗い出しから実施までを自分自身でマネジメントを行うようになりました。ここで今まで自分が如何に人頼みでタスクを貰い、業務を行っていたのかを理解しました。また、SESの方へタスクの割り振りも担当をし、SESさんに協力してもらいながらチームのマネジメントを行いました。
また、API Gatewayの"リプレイス"ということで現行API Gatewayチームの方とリプレイスについてのMTG、インフラさんとデータ移行についてのMTGなど、自チーム外の方とのやりとりを私が担当することになり、ベンチャーとは異なる大企業での働き方について学ぶきっかけになりました。
このプロジェクトでは特に自走することを学ぶ機会になりました。今まで如何に人に判断を委ねていたのかを痛感し、1人の社会人として成長のきっかけとなりました。
日本有数のトラフィックの高さに魅力を感じ入社を決めました。
vue.js, RaspberryPi, Python, Kubernetes, Flask, Express, Docker
副業としてさくらインターネットの研究所で IoTの研究に携わっていました。
「研究」という分野なので詳しくは共有できませんが、IoTとコンテナ技術を用いて新しいエッジコンピューティングの研究を行っていまいした。
RaspberryPiとk3s（Kubernetes実装の一つ）を用いて、分散システムのようなものを作成しました。
担当した箇所としてはフロントからインフラ（RaspberryPi）まで、マネジメントとR&Dの深いところ以外の実装を行いました。
保守運用する必要がなく開発のみで良い（研究の実証）という性質上、技術スタック的にはフロント・バックエンド・インフラ、技術スタックが多くなりましたがそれぞれ最適な技術をつかうことができて納品も行え、スキルアップ的な面でも非常に楽しい副業だったと思っています。
Ruby on Railsをメインで0->1の開発に携わらせていただくことを何本かしました。
Rails, slim, MySQL, jQuery, AWS, PHP, JavaScript, flash, CSS, ActionScript3
受託とかでWebとかゲームとか作ってました。
ゲーム屋さんでは1人で自社ライブラリを改修しながらゲームを何本か作ったり、Adobe(Flash, PhotoShopとか)をポチポチしてました。
Web屋さんはいくつかお世話になったのですが、特に記憶に強いのはBtoBでRailsとAWSの開発を行ったことです。
内定が決まってから仕事を探して、夏頃から3月31日まで半年ほどお世話になりました。
最初はRailsの新機能追加を行って、後半はAWSで構築されたインフラの改修を任せていただきました。
モニタリングツールの選定導入とかコンテナ化とかとか、今思えばSRE的な業務をしてた感じですね。
- JAWS-UG東京 - connpass
- 2023年7月から、JAWS-UG東京支部の運営をやっております。
- 入門 Docker
- Docker入門者向けのgitbookを作成しました。
- 「はじめてのSRE：サービスを止めない仕事術 - Aidemy」
- 株式会社アイデミー様で、SREについて説明する動画（コース）の作成に携わらせていただきました。