msht

自己推薦一覧

自己推薦はありません

3年後の目標や野望


楽しいものづくりを続ける

楽しいチームで楽しいものづくりが続けられるのが一番幸せなことかなと。 現在はkubernetes + SREの領域でバリューを出せているので、その方向で更に力を付けつつ、時代の流れに合わせて、楽しくものづくりをしていくために必要なことを身につけていきたいと考えています。

年収評価シート

プロジェクトカテゴリ
担当工程
役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

プロジェクトカテゴリ
担当工程
役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

2015年/2年以上

web接客サービスの可用性向上

## 概要 - 5000万リクエスト/day 程度の規模 - サイトにタグを埋め込むapi形のweb接客ツール - タグを設置したサイトでエンドユーザーごとにページ閲覧履歴やコンバージョン履歴を記録し、エンドユーザーの行動に応じてウェブ管理者がアクションを取ることができるもの - SRE / QA エンジニアとして参加(特に名乗っているわけではないが業務内容を名前にするとこの辺りが当てはまる) - テスト自動化により後方互換性の確保を容易にした - メトリクス環境・ログ基盤を構築し、それを活用したボトルネックや問題の検出・改善 - バグや問題の解決・長期化した問題のフォローアップ - アプリ層・インフラ層を問わず - 検出した問題のアプリケーションコード修正 ## テスト自動化 - テスト項目の洗い出し - Selenium / webdriver を使った自動ブラウザテストを作成 - フレームワークはcapybara(ruby)を使用 - ユーザ毎に持つステータスが多くを占めるツールの特性上、テストパターンが膨大になり、更に単純な並列化も難しかったため、既存のツールが使えずに並列の仕組みを作る必要があった - ブラウザテスト特有の問題(時々発生するタイムアウトや一時的なネットワーク不調など)の対応として、リトライの仕組みを整備 - あまりやりすぎると本当にテストが失敗していた時は無駄に時間がかかるため、バランスや見極めが難しかった - 2段階のリトライフローを作成し、最初failしたものはすぐにリトライを続けず、一旦プールして最後にもう一度まとめてリトライすることで、一時的な不調によるfailを回避 - 最終的に人が見るのが必要な部分は失敗画面のスクリーンショットやログを専用のwebページを作って見やすくなるようにした - とにかく手作業を最低限にすること、どうしても必要な部分はその労力を抑えることを意識した ## Kubernetes環境下でのモニタリングとログ基盤の構築 - アプリケーションを Ruby on Rails から Scala に移行するプロジェクトがあり、同時にインフラを AWS ElasticBeanstalk から Kubernetes に移すことになり、モニタリング環境を用意する必要があったので、kubernetes が公式サポートしている Prometheus + Grafana の環境を構築した - 今でこそhelmや公式ツール等でパッケージ化されたものがあるが当時はその辺りも貧弱だったので、自前で構築して仕組みを理解することができた - 足りないメトリクスがあればgolangでexporterを作る - alertや電話通知は最低限にした(無駄な通知は緊張の無駄使いなので) - 緊急以外のものを捨てるのではなく、受信チャンネルを複数にして、レベルやすぐに対応する必要性によって振り分けた - アプリケーションがフレームワークを使用しなかったため、ログ基盤もゼロから考えて構築する必要があった - 基本的には AWS CloudwatchLogs を使い、アプリケーションの詳細ログなど量が多いものや閲覧機会の少ないものは S3 + athena でコストを抑えた - コスト面からElasticSearchは使わず、json形式を有効活用することでCloudwatchLogsでも実用十分な仕組みを作成した - デバッグする上で必要な項目、どのような構造にすれば必要な情報に速くアクセスできるかを考えた - サマリログと詳細ログの2つを出し、まずはサマリログを見て、必要に応じて詳細ログを見るようにすることで、ログを閲覧時の無駄を減らした - 単純にメトリクスが取れないものはログを集計してメトリクス化する ## Kubernetesクラスタの運用 - システム改善からトラブル対応までkubernetesとサービスのインフラに関わることは全て見ていた(1人担当だったので…) - 前任が辞めた流れで引き継いだ形 - リリース時はEKSがサービス開始前だったため、kube-awsというツールでAWSに自前のクラスタを展開して運用しており、Kubernetesのシステムそのものに関する知識がついた - 特に今までなんとなくで使っていたx509認証やコンテナネットワーク周りを把握することができた - 運用に便利なアプリケーションやコンテナイメージの作成・deploy - コミュニティで最新情報のキャッチアップ ## アプリケーションのパフォーマンス改善 ### - データベースread負荷の軽減とレスポンス改善 - スロークエリ洗い出し、インデックス見直し、select範囲の無駄を削減するなどして継続的に改善 - __トータルでcpu使用率を50%以上軽減__ - __selectクエリの平均レイテンシを1/2以下に__ ### - 遅延リクエスト解消 - 特定の条件下で起こるレイテンシの遅延をロジックの見直しやオプティマイザの調整をすることで改善 - __遅延リクエストの数を50%以上削減__ ### - 継続的なレイテンシの改善 - 詳細なメトリクスやログから問題のある処理やボトルネックを探し出して解消 - __LB計測でのリクエスト平均レイテンシを1/2以下に__ ## 解決した問題など ### - 原因不明の高負荷 - ある時期から決まった曜日、時間帯で急激に負荷が上昇する現象が発生した - 全体のアクセス数に変化は見られなかったが、ログを解析していくとあるユーザIDのひとつがクローラーで、莫大な量の閲覧履歴を持っており、決まった時間帯に作動していることが判明した - UAでbotやクローラとわかるものはアクセスを遮断し、アクセスの多いユーザを監視することにした - 根本的なアプリケーション側での対策として、取得レコード数の上限を決めるというものがあったが、営業・運用サイドと折り合いをつけられなかった - まさかひとつのユーザが原因とは全く考えていなかったので解決に時間がかかってしまい、またモニタリング体制の貧弱さを痛感したが、この経験を後のモニタリング環境構築に活かすことができた ### - レポートの異常 - タグが設置されているサイト毎に、ツールの効果を閲覧できるレポートページがあり、そこに異常が見られることがあった - 算出される一部の数字が思ったより1割くらい大きいことがたまにある、というようなもの - 開発チームで算出ロジックを何度見直しても、異常が見つけられず、ステージング環境で再現もできなかった - こちらで調査をしたところ、レポート用のデータがデータベースカラムの最大長を超えていて入り切らないものがそっと切り捨てられていることが判明した(エラーにならず黙って切り捨てられるので気付くのが難しかった) - 振り返ってみれば簡単な設計ミスではあるが、このような形で異常として現れると原因に到達するのはかなり難しく、粘り強さと嗅覚が必要だった ### - 顧客サイトに依存する動作異常 - api型サービスの特徴として、埋め込み先のサイトに依存する動作異常があった(javascriptの競合など) - 手元の環境では再現しないため、顧客からの連絡により表面化することがほとんどで、かなり時間が経過しているケースもあり、ツールの信用を落としてしまう事態にもなってしまった - 顧客ごとに使用状況を取得し、変化があった場合に知らせる仕組みを作った - 顧客によっては施策で使用状況が変わることも当然あるので、単純な比較だと誤検知が多かった - 週末限定の施策がある、最近セールをしていた、など - 評価期間を変えて複数の指標を取る、平均値と中央値を比べる等で誤検知を減らした ### - コンテナが完全にハングすると自力復旧不能になる - Kubernetes環境にてCPU使用率を基準にコンテナをオートスケールさせる仕組みを取っていたが、想定を超えたアクセスのスパイクや瞬間的なネットワークの障害によるリクエストの偏り等でコンテナに急激な負荷がかかるとコンテナがハングしてCPU使用率が取得できずスケール不能に陥り、人の手を入れないと復帰できない問題があった - イベントやコンテナ等のヘルスを監視して、該当イベントの発生率やヘルスチェックのfail比率など数種類の指標からクラスタの異常を判定し、この状態になったと判定された場合はスケールさせるツールを作った - (アプリケーションやコンテナ側での対策が筋なのだがこの件は解決に至ってない) ### - その他 - __他で解決できず長期化してしまった問題の調査を依頼され解決に貢献することが多かった__

マネージメント能力

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
あり
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

- 英語 - 会話よりは文章の読み書き - 現在のkubernetesのような速い変化をリアルタイムで追っていくためには英語力が必要だと痛感している - コミュニティでちょっとしたやり取りをするのにも非常に時間が取られてしまっている - golang - これもkubernetesの話になってしまうのだが、これに深く関わる上で必須スキルだった - ちょっとしたアプリケーションくらいなら作れるようになったが、まだまだ - プログラミングの能力は高い方ではないので、本格的に取り組んでいきたいという気持ちがある

エンジニアとして影響を受けた本を教えてください

未入力です

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

- ひとつの物事に注力できる - じっくり取り組める

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
分析力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
趣味は仕事 / 起業/創業期のベンチャーにいた
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代後半
好きな Text Editor
sublime text
希望勤務地
東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
600万円
ただいまの期間
ドラフト開催中

  • 参加者は企業から指名が入ります
  • ドラフト指名に返答できます
  • レジュメを更新できます
  • 審査は停止しています
ご意見箱

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

msht
今年で30代後半
sublime text
参加ステータス
不参加
転職意欲
参加回数
2回
累計平均提示年収
676 万円
SIGN UPSIGN IN


このサービスを友人に薦めたいですか?