tkg216

## プロジェクト概要 進行中のプロジェクトで、2023/10よりSREチームが発足しセキュリティ分野に注力する計画中です。 エンジニアの中でSRE専任ロールは自分1人という状況で3プロダクトに対してのSREとしての様々な取り組みをしていく。 # アーキテクチャ改善 【課題】 - ECSの同一タスクにサービス本体とAdminが同居していることで耐障害性が低い - インフラ構成の変更を試す環境がない、試す方法が確立されていないので問題が放置されていた 【解決策・工夫点】 - ECSサービスの単位で分離 - 新規AWSアカウントを払い出し、検証用環境を構築し、自由に検証できるようにした 【成果】 - 狙い通り分離することによって耐障害性を高めることができた - 検証しやすい環境の構築を通してブラックボックス化されていたデプロイの仕組みを1から理解することができ、社内展開した - その検証環境が後にインフラ領域にチャレンジするメンバーが活用することができた # オブザーバビリティ向上・可用性向上 【課題】 - Datadogを入れたけど使っていない - デバッグの方法が非効率かつ且つ属人化している 【解決策・工夫点】 - 実際のデバッグ時の方法について開発者にヒアリングを実施し、実際のデバッグシーンを見せてもらうことで業務理解を深めることに努めた - RUM→APM→Logが紐づいていなかったので紐づけることでツールや機能の行き来する負荷を減らすようにして、エンジニアに対してデモを実施 - RUMのセッションリプレイやResourcesの表示などでデバッグのしやすい環境を構築 【成果】 - 使っていなかった機能のメリットを理解してもらえて効率改善を体感してもらえた - 監視・モニタリングツールの統一や選定する課題が先送りされていたが前進した # コスト最適化 【課題】 - これまで副業の業務委託の人に対するクラウドインフラ領域の依存度が高かったため、コスト最適化があまり進んでいなかった - スタートアップであること、円安であることからなるべくコスト削減をしたい - 他のSRE領域もあるためコスト最適化に長期間時間をかけられない 【解決策・工夫点】 - クイックウィンである範囲を一旦の活動のゴールとすることに設定 - コスト構造を把握するために、AWSではCostExplorer、Datadogでは契約内容の見直しから着手 - 書籍にあるような基本的な対策、他社事例などを積極的に採用 - 当初は会社の中で1番大きなプロダクトが対象だったが、他チームのエンジニアと連携しながら横展開も並行して進めた 【成果】 - Datadogで大きなコストロスをしている契約内容を検知して是正した - AWSでは、Googleカレンダーと連携したサーバーやDBのスケジュール停止の機構を導入することや、不要リソースの削除、RI/SPの導入、FARGATE SPOTの導入、ARM化などを実施 - 合計として$3500(約30%)ほどの節約効果を実現 - 既存のインフラ構成への理解が高まったこととプロダクトチームメンバーと協力して進めることでプロダクト開発者のインフラへの理解度が高まった - クイックウィンとしての施策は一旦、時期を区切ったが継続的に打てる施策を情報収集しながら日々試算や実践する習慣がついた # その他 - AWS全体 - 権限管理: 全員Administratorだった状況に対してチーム構成に沿った権限構成へ変更 - CloudTrailやGuardDuty、AWS ConfigなどのサービスをOrganizationsレベルで設定 - enpayプロダクトへのSRE活動 - サービス本体コンテナとAdminコンテナをECSサービス単位で分離することで可用性の向上 - AWSリソースのアラートを設定しメモリ不足などに事前に気づける最低限の整備 - CDKV1のEOL対応 - WAFのログ設定 - デプロイフローのドキュメント化とSWEへのレクチャー - ログのフォーマット改善 - SytemAlertsの整備 - モニタリングダッシュボードの整備 - SLO策定 - redashサーバーの共通化 - 各プロダクト・各環境ごとにredashサーバー(ECS+RDS)を構成していたものを、共通redash化してPrivateLink経由で各DBに接続する構成に変更することでコストの削減とURLの統一による利便性向上に貢献した

## プロジェクト概要 - 目的: オートチャージ機能、支払い機能を備えたモバイルアプリの新規立ち上げ - 自分の役割: エンペイJoin直後にSREとして参画 - チーム構成: PdM1名、モバイルアプリエンジニア2名、バックエンドエンジニア2名、自分 【課題】 - 入社直後のプロジェクトで周りからの信頼を得る必要がある - 同時にインフラ領域に挑戦したい若手エンジニアの教育・フォローをする必要がある - 自分の慣れていないECSサービスでインフラ構築する 【解決策・工夫点】 - まずは、自分の経験や実績の多い領域から着手し、信頼を高めることコミュニケーションの円滑化に努めた - 入社前後に既存プロダクトのインフラ・CI/CDパイプラインの構成をキャッチアップする機会があり、その際に課題を洗い出し、その結果を踏まえGitHubFlowのCI/CDパイプラインを提案 - 若手教育の観点では中規模なマイルストーンを設定し、細かいコミュニケーションを取りつつ、進めた。一方でプロダクトとしてもスピード感を持ってローンチまで辿り着きたいところがあったため、バックエンド開発に必要なStaging環境構築などの開発全体で高い優先度のものに遅れが出ないよう優先度決めを行なった。逆にCI/CDパイプラインとして一旦デプロイができる状態にしてからB/Gデプロイメントへの移行などを腰を据えて行うことにした。 【成果】 - 開発の早い時期にCI/CDパイプラインを構築したことでリリース後の開発プロセスを意識しながら開発に取り組むことができた。そのことで、開発期間中にCI/CDパイプラインへのフィードバックを反映させながらプロジェクトを進めることができ、リリース後数ヶ月経過してもCI/CDパイプライン周りで問題が発生していない - マルチプロダクトで1人SREという会社の状況で、CDKなどのIaCをみえる人材が不足していたが、若手エンジニアの努力もあり、社内でAWSやCDKに知見を持ったエンジニア数が増え組織編成の際の柔軟度を高めることができた - 自分自身、サーバーレスのLambdaを使う経験が多かったが、コンテナオーケストレーションサービスのECSについて知識とスキルを得ることができた。

## NAONAとは コミュニケーション可視化のプラットフォームです。オンライン/オフラインのどちらのコミュニケーションにも対応していて、コミュニケーションデータの解析・蓄積やアプリケーションを作成するための要素を提供しています。NAONAプラットフォーム上で、1on1やグループディスカッションなどのアプリケーションを開発しています。 ## プラットフォーム拡張(管理画面とREST API開発) 【課題】 - (プロダクト) プラットフォームの管理画面でCRUD操作できないデータがあり運用負荷が高かった - (プロダクト) アプリケーションが使う機能として利用所許諾機能を追加開発する必要があった - (プロジェクト)入社直後の既存システムの理解度が低い状態で協業先の業務委託メンバーと開発を推進する 【解決策】 - スクラムに入る前のオンボーディング期間でプロトタイピングをしながら構成をキャッチアップし、これまでの工数見積もりよりも精度が高く、スピードのある開発サイクルを実現することができた。 - 実際には、オンボーディングとしてAPIを実行したりゆっくりと検証することをする期間として与えられていたが、プロトタイピングの提案を行い、スクラムに想定よりも早く入ることを提案した。 【成果】 - 予定工数の2/3程でリリースまで完了することができた。 - オペレーションの運用コストを1/3程に短縮 ## PoCアプリ: 面接練習アプリの開発 NAONAを面接練習に使えないか検証するためのWebアプリケーションを実装。Nuxt.js/TypeScript, Amplifyで構築。アプリケーションの機能としては、面接練習を開始すると、問題が表示され、マイクを使って回答すると回答内容についてのフィードバックが得られるもの。言い淀みや話速などの指標で回答が上手く行えているか練習生が振り返りに使うことができる。PoCアプリのフィードバックを得るため、転職時に親交を深めたエージェントの方にフィードバックをもらえるようにアポイントを取ることや営業に同行しながらヒアリング・機能検討を進めた。 ## PubSubAPIの構築 【課題】 - アプリケーションのユーザーが操作したことを他のユーザーの画面に反映させたい機能要望 - 必要な機能ではあるが実装コストが高い場合を危惧してなかなか優先度が上がらなかった 【解決策】 - AWSのAppSyncをキャッチアップしGraphQL Subscription機能を使えば実現できることを自力で調査 - AWS SAとの打ち合わせを設定し他の実現方法も含めてチームメンバーおよびAWS SAと議論の場を設けた - API GatewayのWebSocket方式をAWS SAからは勧められたが自分の検証結果を鑑みると開発工数などは低いためAppSyncを採用することを提案 - プロトタイプを作り社内で採用実績のなかったGraphQLとAppSyncの勉強会を実施 - 新技術の提案・導入だけで終わらないように、フロントエンドの実装例などもドキュメント化 【成果】 - 短期間でGraphQL Subscription機能を使えるAPIを構築することができた - 要望の上がった背景の機能以外の機能でも使われる汎用的なAPIとなった - フロントエンドで機能実装する際に低い工数で問題なく導入することができた →こちらをテーマにJAWS DAYS 2022 PREEVENTで登壇 ## ブラットフォーム(CI/CDパイプラインの刷新) 【課題】 - 外部ベンダーが構築したJenkins製CI/CDパイプラインを内製化・エンハンスできない - 社内外にJenkinsに対する知見を持ったエンジニアがいない - 既存のリリースフロー、パイプライン構成ではリリースに時間がかかる 【解決策】 - AWS CodePipelineをベースにしたGitHub Flowベースのパイプラインに刷新を提案 - 継続デリバリーやThe Twelve-Factor Appのベストプラクティスに則ったCI/CDを設計 - 移行用の検証環境を用意して移行のリハーサルまで実行することでパイプライン移行実施時に起こり得るトラブルを洗い出してから移行本番に臨むようにプロジェクトを推進 【成果】 - 目立ったトラブルが発生することなくCI/CDパイプラインの移行に成功 - リリースにかかる工数が大きく短縮 - リリース頻度が上がり、リリースへの安心感が向上 - 別モジュールのCI/CDパイプラインでも同じ構成を採用することに繋がり社内にノウハウが溜まった ### プラットフォーム(監視の仕組み刷新) CloudPackに依存していた監視の仕組みをCloudWatch MetricsやSNSなどのAWSサービスをベースとしたSlack/Backlog通知をする監視基盤に刷新 ## 内製Web会議開発 【課題】 - 既製品のWeb会議アプリで内蔵スピーカーを使うユーザーの音声をNAONAアプリケーションで音声を解析しようとすると他者音声と区別がつかないため、精度が著しく低下する課題があり、その影響でディスカッションの評価制度に影響を与えていた 【解決策】 - 粘り強くWebRTC関連のSDKの調査や技術調査を行い、同じブラウザ内であればWebRTCを使ったWeb会議の音声と内蔵スピーカーが拾う音声を分離して解析できることを突き止めた - ブラウザ版Web会議アプリを内製化する開発工数とライセンス費用がネックになっていたが、Amazon Chime SDKを使うことで簡単にデモアプリを作成し初期費用なく利用できることを調査で明らかにして社内で共有した - Amazon Chime SDKを有効に活用するためには社内で利用実績のなかったReactを使う必要があったがチャレンジすることを提案した - チームメンバーのマネジメントとReact/ChimeSDKのノウハウ伝授をしながら開発を進める 【成果】 - 音声解析精度が上がり、サービスを展開する上で重要な顧客との提携が大幅に前進した - ChimeSDK、React、API(APIGateway+Lambda+DynamoDB)、EventBridgeなどのスキルを高めることができた ## その他 ### Slackでのオープンコミュニティ促進 チームにジョインした当初、Slackは導入されていたがDMやプライベートチャンネルがメインで使用されていた。自分自身も新しく参画した立場で少しやりにくさを感じたのと、今後、より深い議論をオープンにしていくことが必要だと感じたため、パブリックチャンネルをメインにした運用へ変更を決定した。協力的な姿勢で取り組んでいただけ、リモートワークがしやすくなったという声などをいただけた。 ### 開発勉強会としてのセキュリティ勉強会を開催 セキュリティ対策を全くできていないわけではなかったが、開発、チームとしてここまで出来てるからOK、あとはここはやらなければいけない、のような具体的なものを自分、チームが持てていなかったのを課題に感じ、企画、提案、実施中。 ### EM役割 開発マネージャーが異動となり、明確なマネージャーが不在となり、自分が開発マネージャーとしてやるべき動きをやることが増えるようになった。例えば、メンバーとの1on1(明確なポジションではないので完全な定期開催というより個々人と話す機会を増やしながら進めた)や、開発全体でのKPTなどを開催し、タスクとして落とし込みなどを行なった。

# 概要 プライベートで友人と2人でiOSアプリを2作開発・リリース、webアプリケーションを1つ開発しました。 # 背景 元々エンジニアでなかった友人と、アプリ開発経験のなかった自分の2人で、本業でなかなか新しいサービスを開発できない歯痒い想い共有し、個人活動で晴らしたいという想いで、意気投合し、モバイルアプリとwebアプリケーションを開発しようと取り組み始めました。 # 苦労した点 ### (1) アイデア出し、要件仕様検討 「世の中に役立つアプリを作る」という目標の元、どんなアプリを作るか検討を重ねました。思いついたアイデアが既に実現されていたり、アイデア出しに時間が取られてなかなか開発までいけないなど苦労しました。 その中で、 ・アイデアフレームをアプリで実現するFastIdeaというマンダラチャートとしりとり法が使えるアプリ(iOS) ・スポーツチームとスポーツをしたい人をマッチングするTipOffというアプリ(iOS) ・技術書に特化した技術書レビューサイト(web) の2つのアプリを開発しました。 ### (2) 未経験のアプリ開発をスピード感を持って実施すること 　2人ともモバイルアプリについて素人でしたが、半年間で2作リリースしようと目標を立て、開発を行いました。iOSの基礎から学習し始め、休みの日に、お互いの家で開発作業をしたり、カフェで話し合いを繰り返したりしながら、技術習得、開発を進めていきました。 　モバイルアプリやクラウドの知識習得や、CircleCIやGitHubなどのツールの導入も積極的に行いました。その結果、新しい技術に触れることや、全行程について考えることの楽しさと難しさを経験することができました。

# リモートアクセスサービスの機能拡張 【プロジェクト概要】 リモートアクセスサービス機能の負荷分散を実現する機能拡張プロジェクトでプロジェクトリーダーとして担当。 【担当フェーズ】 技術調査、基本設計、詳細設計、実装、テスト 【担当業務】 ・メンバーの立ち上げ ・調査内容の取りまとめ、精査 ・業務内容のアサイン ・アーキテクトレビュー 【実績・取り組み】 ### メンバーの立ち上げ 自分以外のメンバーは新規の業務委託メンバーだったため、既存のサービスに対する理解がなく、メンバーの立ち上げから行う必要がありました。プロジェクトリーダーとして、作業内容を伝えるだけでなく、背景や目的を理解してもらうよう務めるように心がけたことで、メンバーからの提案なども行われ、QCDを達成することができた。 ### アーキテクチャ決定 リモートアクセスサービスの負荷分散を実現するためには、仲介サーバーとUTMサーバーが上手く連携し、割り振り方法の決定、IPアドレス付与方法の決定などの課題があり、これらは未調査のものであった。 それらの方式を決定するために、各課題に対して、複数アイデアを出し、実現性やコスト、メンテナンス性などの観点からQOCで比較し、最適なアーキテクチャーを検討し、グループ内のアーキテクトチームのレビューを重ねることでアーキテクチャを決定することができた。 ### 性能測定ツールの作成 大量のクライアントが同時にアクセスするケースをテストする手段が、端末を大量に動作させることは難しく、今までツールが存在していなかった。 負荷分散の実現を確認するためにも性能測定ツールは必須だと感じ、提案・開発いたしました。今までプロジェクトに導入実績のなかったterraform, Docker, GCP, Ansibleを組み合わせることで実現できることを自ら、考案し、導入提案、ツール開発を行いました。技術を選定した背景は、大量のインスタンスを同時や順次コントロールする必要があったため、クラウド上で大量のインスタンスをTerraformで作成し、Ansibleで操作することで解決できるのではないかと考え、導入した。TerraformやAnsibleは知らなかったツールでしたが、業務外活動(Hardening)で情報を得ることができたもので、その知識を業務にフィードバックすることができた。

# 法人向けみまもりサービス業務アプリの開発 【プロジェクト概要】 介護事業社等がwebアプリケーション上で、高齢者をみまもる新規サービスの開発 【担当フェーズ】 要件定義、画面設計、基本設計、詳細設計、実装、テスト 【実績・取り組み】 開発メンバーが社内に不足しているため、オフショアを活用した開発を推進しました。 中でも、業務でwebアプリケーションを1から作る経験は初めてだったが、XDを使った画面設計や要件定義などの上流工程から取り組みました。XDを使ったワイヤーフレーム を用いて、事業開発グループ側と折衝することや画面の詳細設計をする新しい経験など慣れない点もあり苦労しましたが、ユーザー視点やビジネス視点を持つことの大切さを学ぶことができたと思います。 全体の設計としては、運用コストを抑えることのできるサーバーレスアーキテクチャーを採用しました。基本的には、フロントエンドにVue.jsを採用しシングルページアプリケーションを構築し、APIと分離することでオフショアを使った開発をしやすいようにした。さらに、1つのシングルページアプリケーションで構成するのでなく、管理画面とアプリ画面(みまもり電池連携機能)とログイン画面を別のVue.jsで構成し、cloudfrontのbehaviorに登録する設計を採用することにした。このことによって、サービスイン時は、みまもり電池連携機能のみを持つアプリケーションだが、別のアプリケーションとの連携機能を持たせたくなった場合に、アプリ部分のVue.jsのプロジェクトを差し替え、追加することだけで実現ができるアーキテクチャーを採用した。 また、複数のVue.jsやAPIを手動で複数環境(dev, stg, prod)にデプロイするのは、手間でもあり、ミスが発生しやすいのでデプロイパイプラインの導入を検討した。レポジトリには、GitLabを使っていたので、複数のCodeCommitに対して、ミラーリングができず、複数環境にデプロイパイプラインの構築ができないという課題があった。設定値のレポジトリとアプリのレポジトリは分離し、アプリのレポジトリは、GitLabからGithubにミラーリングし、CodepipelineとCodecommitを用いることで、複数環境へのデプロイパイプラインの構築をした。

・AWSに関するアドバイザリー ・アーキテクチャ選定 ・CDKを使ったインフラ構築およびCI/CD Pipelineの構築をし、プロパーへのレクチャーを実施 ・Cognito、WAF、ControlTower等の導入