リーと申します。台湾出身で、現在は大阪に住んでいます。
台湾のIT業界で10年以上、インフラエンジニア・SREとして経験を積んできました。直近では17LIVEというライブ配信プラットフォームで、シニアSREとしてGoogle Cloud上のKubernetes基盤の構築・運用を担当しました。
特に、CI/CDパイプラインの刷新でデプロイ時間を約75%短縮したり、クラウドコストを50%削減するなど、具体的な成果を出してきました。
昨年JLPT N2を取得し、日本での長期的なキャリアを目指しています。ピクシブさんのVision 03「安全で安心して利用できるプラットフォーム」を支えるインフラの仕事に、自分の経験を活かしたいと考え、応募いたしました。よろしくお願いします。
ピクシブさんのEntrancebookに「クリエイターの経済活動・人生を支えるインフラでありたい」という言葉があり、とても印象的でした。BOOTHやpixivFANBOXのような決済サービスが止まることはクリエイターへの直接的な影響になる。そのプレッシャーの中で安定稼働を実現する仕事に、自分のSRE経験を活かしたいと考えています。
また、オンプレとクラウドを両方扱える環境で、自分のスキルの幅をさらに広げたいという思いもあります。
17LIVEに入社した当初はフルリモートで働いていたのですが、2年前に出社規則が変わりました。その時点ですでに日本に移住していたため、台北のオフィスへの出社が難しくなり、退職しました。
退職後は日本語学校に通い、N2を取得しました。この機会に、以前からずっと惹かれていた日本の仕事文化の中で、SREエンジニアとして挑戦したいと考えています。
3つあります。
1つ目は、課題を自分で見つけて解決する力です。指示を待つだけでなく、コスト削減や作業速度の向上など、会社にとってプラスになる問題を自分で見つけて改善してきました。
2つ目は、適応力と継続的な学習力です。日本語も技術も、自分でやると決めたことは毎日コツコツ続けられます。新しい環境に直面した時は、まず真似して、理解して、自分の知識として定着させるという流れで学びます。
3つ目は、チームへの知識共有です。自分の知識をチーム全体に広めることを大切にしており、マニュアルを作ったり、勉強会を開いたりして、チームみんなが働きやすくなるよう貢献してきました。
アプリケーション開発の実務経験がまだ少ないです。インフラ側からサービスをサポートすることは得意ですが、Webサービスのコードを書く経験は限られています。
今後はそのギャップを埋めるために、開発チームと積極的に連携し、アプリケーションの視点からもインフラを考えられるエンジニアになりたいと思っています。
まず影響範囲を確認して、すぐに上司とチームに報告します。そして原因を特定し、復旧を最優先に行います。
原因がすぐに分からない場合は、一時的にロールバックしてサービスを安定させてから、改めて原因を調査します。一人で悩まず、他のメンバーにも相談します。
解決後は必ず再発防止のための記録を作ります。根本原因を直して、マニュアルを更新し、可能であれば自動化の仕組みを追加します。
レガシーサービスをコンテナへ移行するとき、設定ミスで一部のAPIキーが正しく引き継がれず、一部のクライアントに影響が出てしまいました。
気づいた後はすぐに原因を特定して、正しい環境変数の設定に更新しました。
再発防止として、コンテナ移行時のチェックリストを作成し、チームで共有しました。この経験から、レガシーシステムの移行時は設定の引き継ぎを必ずダブルチェックする習慣が大切だと学びました。
まず入社後は、ピクシブさんのインフラ環境（オンプレ・クラウド両方）をしっかり把握して、早期に戦力になることを目指します。
中期的には、システムの自動化・標準化に貢献して、チーム全体の運用効率を上げることに取り組みたいです。属人化を減らして、誰でも安心して運用できる環境を作ることが目標です。
将来は、チームをまとめるリーダーとして、メンバーの成長にも貢献できるエンジニアになりたいと思っています。
理由は3つです。設定をコードで管理できるため、Gitで変更履歴を追えます。次に、並列実行のサポートが充実しており、ジョブを同時に走らせることで時間を短縮できます。そして、Dockerとの親和性が高く、イメージの事前ビルドが簡単でした。Jenkinsはれ属人化しやすい点が課題でしたが、CircleCIでチーム全員が設定を読み書きできる環境になりました。
各サービスによってビルド手順が少しずつ違っていたため、共通テンプレートを作る際に、どこを共通化してどこを個別対応にするかの判断が難しかったです。対応として、まず全サービスのビルド手順を一覧化して共通部分を洗い出し、4ステップに標準化しました。差分は環境変数で対応できる設計にしました。
ピクシブさんではGitLabを使ったCI/CDの構築・運用を担当するとのことで、この経験が直接活かせます。CircleCIとGitLab CIは設定のコード管理や並列実行の最適化という思想が共通しています。また、15以上のプロダクトを持つピクシブさんの環境では、標準化されたパイプラインテンプレートの設計経験が特に役立つと考えています。
設定ミスで一部のAPIキーが正しく引き継がれず、一部のクライアントに影響が出てしまいました。すぐに原因を特定し、正しい環境変数に更新しました。再発防止として移行用チェックリストを作成し、チームで共有しました。この経験から、レガシー移行では設定の引き継ぎを必ずダブルチェックする習慣が大切だと学びました。
理由は3つです。サービスごとに独立してスケールできること。ローリングアップデートでサービスを止めずにデプロイできること。CronJobを使ってバッチ処理もKubernetes内で統一管理できること。この3点が決め手でした。
私の経験はGKEというマネージドサービスが中心です。k0sはオンプレミスで動くため、ネットワーク設定やノード管理を自分たちで行う必要があると理解しています。ただ、Pod・Deployment・Service・CronJobなどのコアな概念は共通です。まずその知識を活かしながら、オンプレ特有の部分はキャッチアップしていきたいと思っています。
SPOF（Single Point of Failure）は、その部分が止まるとシステム全体が止まってしまう箇所のことです。OrderPallyの場合は1台のVMにすべての機能が乗っていたため、そのVMが落ちるとサービス全体がダウンしました。解決策として、VMを複数台構成にしてロードバランサーで分散させ、1台が落ちても他のVMがリクエストを受け続けられる冗長構成を実現しました。
理由は2つです。1つ目は可用性の向上。VMと同じ場所にDBを置くとVMが落ちた時にDBも止まります。CloudSQLはGoogleが管理する高可用性サービスなので、VMとは独立して動き続けます。2つ目はスケーラビリティ。アプリとDBを分離することで、それぞれ独立してスケールでき、負荷が増えた時も柔軟に対応できます。
ピクシブさんでは秒間20万リクエストを安定処理するインフラが必要で、BOOTHやFANBOXのような決済サービスのダウンはクリエイターの収益に直接影響します。「単一障害点の排除」「冗長構成の設計」「DB分離による安定性確保」という経験はそのまま活かせます。Entrancebookにある「クリエイターの経済活動・人生を支えるインフラ」という言葉が印象的で、その責任感を持って安定したインフラを守りたいと思っています。
まずGCPのコストレポートで、どのサービスが一番コストを使っているか可視化しました。一番大きかったのはログ保存コストとGKEのコンピューティングコストだったので、この2つを最優先に対処しました。未使用リソースは削除のリスクがあるため、監視ツールで使用状況を確認してから対応する手順を踏みました。
おっしゃる通りで、最初にリスクを検討しました。対策として、エラーログは100%残すようにしました。問題が起きた時に必要なのはエラー情報であることが多いためです。正常リクエストのログは1/100に減らしましたが、トレンド分析には十分な量でした。またヘルスチェックやBotトラフィックは「ノイズ」として事前に除外しました。
GCPのコスト管理ダッシュボードで施策実施前後の月次コストを比較しました。施策は段階的に実施したので、どの施策がどれくらい効果があったか大まかに把握できていました。パフォーマンスへの影響はDatadogで監視し、レスポンスタイムやエラーレートに変化がないことを確認しながら進めました。
CI/CD刷新 → 「GitLabを使った複数サービスのパイプライン標準化に活かせます。」
コンテナ移行 → 「k0s環境へのキャッチアップに、GKEでの深い経験が土台になります。」
高可用性構築 → 「クリエイターの経済活動を支えるサービスの安定稼働に活かせます。」
コスト削減 → 「大規模インフラのコスト最適化を、パフォーマンスを維持しながら進めた経験が活かせます。」
□ 接続テスト（オンライン面接の場合）・静かな場所・背景を確認
□ 職務経歴書を手元に用意（印刷 or 画面表示）
□ 逆質問を3つ選んでメモしておく
□ 「k0sはGKEと違うが、コアは共通でキャッチアップできる」の言い方を練習
□ 在留資格（家族滞在ビザ、2027/2まで・更新予定）の説明を準備
□ 数字を先に言う練習：「75%削減」「ダウンタイムゼロ」「50%削減」