ID:70434さん

# プロジェクト概要 ## 目的 社内主力サービスをエンハンスするためのサブサービスの提供 ## チーム構成 - PM 1人 - インフラ 1人 - アプリケーション 3人 ## 担当した役割 アプリケーション # 取り組んだ業務・実績 - API の仕様調査 - アプリケーション/ユニットテストの実装 - RDB 設計 - CI の構築 - 顧客からの問い合わせ対応 # 工夫した点 ## 静的解析・ユニットテストの CI 構築 ### 課題 主力サービスのコードベースはコーディングスタイルに決まりはなく実装者が書きたい様にしていたため、コードが見づらいという問題がありました。 また、ユニットテストが充実しておらずリファクタをする時や修正を加えるときなど、正しく動作することが保証されづらい環境にあり開発速度が低下してしまう問題がありました。 ### 取り組み PHP CodeSniffer と PHPStan という静的解析を開発フローに取り入れました。 開発環境で静的解析が出来るのはもちろん、PR が作成されたら CircleCI で自動に静的解析が走りルールに違反している箇所があれば PR にコメントを残してくれる様な仕組みを構築しました。この仕組みを開発初期に導入することで、後からコーディングスタイルの修正に充てる時間を削減できました。 また PHPUnit も自動で走る環境を構築しそれが全てパスしなければ PR がマージできないルールを整備することで、実装したコードが正しいことを証明できるとともに、よりユニットテストを意識したサービス開発をする環境を構築することが出来ました。

# プロジェクト概要 ## 目的 他社サービスのクローズに伴い、そのユーザーを取り込むための機能の実装 ## チーム構成 - ビジネス 2人 - スクラムマスター 1人 - アプリケーション 4人 ## 担当した役割 アプリケーション # 取り組んだ業務・実績 - ビジネスサイドとの要件定義 - クラス設計 - RDB 設計 - アプリケーション/ユニットテストの実装 - オートロードの導入 - CI の構築 # 工夫した点 ## DDD（ドメイン駆動開発）を参考にしたクラス設計の導入 ### 課題 機能追加を行うサービスは 10 年以上の稼働実績があるものの、様々なクラスが絡み合い拡張性や可読性、保守性が高いとは言えず既存の機能のコードを読む時は多くの時間を要すことがしばしばありました。 ### 取り組み アプリケーションの価値を高めるクラス設計を行う手法として DDD がありますが、全く同じことをするのはメンバーの理解や知識レベルが揃っていないと難しいと考え、クラスが持つ責任によってレイヤーを振り分け依存性が一方向になる様な設計を主導しました。ビジネスサイドと要件定義を進めていき顧客マスタ機能において重要なビジネスロジックが全てのレイヤーの依存先となることで変化が少ないものに依存する様な設計を行いました。 この時の社内では初の取り組みであり、データベースが関わる時のパフォーマンス問題やビジネスサイドとのコミュニケーションがまだまだ足りてないなど課題点も多く見つかりましたが、チーム内では以前のコードより可読性が高く仕様変更もし易くなったという声をいただきました。 ## オートロードの導入 ### 課題 前述した DDD を参考にしたクラス設計を行う副作用として、クラス自体の数が増えやすいです。 PHP で動作する本サービスにはオートロードの環境が用意されておらず、必要なクラスを `require_once` によって逐一読み込む必要があました。したがって、クラスが増えていくにつれて `require_once` 忘れやエディタの自動インポートの恩恵を受けることが出来ず開発速度の低下を感じることがありました。 ### 取り組み 既に Docker イメージの CD は整備されているかつ Composer が利用できる状態だったため、オートロードを導入しました。 既存のコードベースにはクラス名が被っている箇所があり全体に適応するのは難しいかつ時間がかかってしまうため、本プロジェクトで実装するコードのみオートロードを有効化しました。 Docker イメージの CD はインフラ部門の方が管理していたので、現状の CD の状態をヒアリングしつつ検証を進めていき1週間足らずでオートロードが利用できる状態になりました。 現在オートロードの環境は新規プロジェクトでは必ずと言っていいほど利用されるようになっています。

# プロジェクト概要 ## 目的 BigQuery 上のデータを活用し既存サービスをよりエンハンスできる機能を提供する ## チーム構成 - ビジネス 1人 - エンジニア 2人 ## 担当した役割 エンジニア # 取り組んだ業務・実績 - ビジネスサイドとの要件定義 - クラス設計 - アプリケーション/ユニットテストの実装 - アプリケーションの CI/CD 構築 - Terraform を利用したインフラ構築 # 工夫した点 ## 納期遅れによるタスクの巻き取り ### 課題 フロントエンドとアプリケーションの実装担当者が他の業務が忙しくて開発に着手できておらず、当初の予定より納期が遅れてしまう可能性がありました。 ### 取り組み 自分はある程度余裕があったこともあり、自分の担当だったインフラ設計とクラス設計は完了していました。そこで、自分がアプリケーションの実装タスクを巻き取れば間に合うのではないかと考えました。 もう1人のエンジニアには1週間に1度進捗をヒアリングしたり、Asana でタスク管理して今どんなタスクに着手しているか分かる様にしていたおかけで納期が遅れてしまいそうなことにある程度早く気づけたのが良かったと考えています。 また、クラス設計を行う段階で CI/CD を整えていたおかげでデプロイの方法や静的解析の実行方法に気を取られることなくアプリケーション開発が行えた点も良かったと振り返っています。 ## BigQuery の様々なデータを扱える様な設計 ### 課題 BigQuery に保存されている1つのみが新機能で利用されるデータでした。 しかしながら、今回の様に BigQuery のデータを利用して機能を実装する要望が出てくる可能性が非常に高いという話をビジネスサイドからヒアリングしていました。 ### 取り組み BigQuery のデータを読み出す処理において、今後どんなデータを読み出したい要望が起きても最小限のコード追加で済む様なクラス設計を行いました。 具体的な処理としては BigQuery からデータを読み出して S3 をそのデータを保存した上で、さらにその S3 のデータを集計して別の S3 に保存する流れです。クラス設計としては、BigQuery から読み出されるデータとクラスを1対1で対応付け、そのクラスに共通のインターフェースを持たせることで BigQuery から読み込んだデータを必ず指定のフォーマットで扱える様にしました。そうすることで、S3 に保存する処理はそのインターフェースに依存させることでインターフェースさえ実装されたクラス（つまりデータ）であればどんなデータでも保存することが出来るようになっています。 ## 冪等性を意識した処理の実装 ### 課題 BigQuery から読み出すデータは利用ユーザーの全てが対象だったので、およそ数千社のデータを取り扱う処理でした。 したがって、処理が1時間以上かかることは避けられず、途中でもしも実行が失敗してしまった場合に復旧が大変になってしまうことが懸念されました。 既存の機能では何回か実行すると結果が変わってしまう様な処理が存在しており、致命的な問題ではないものの実行が失敗してしまった時のリカバリーが大変だったこともありました。 ### 取り組み 全ての処理において、何回実行しても結果が同じになる様に冪等性が考慮された実装を行いました。実際にリリース直後は考慮不足があり処理が途中で中断してしまう事象が発生しましたが、考慮不足を修正するリリースをし処理を再実行するだけで意図した処理が行われ運用が非常に楽だと感じました。

# プロジェクト概要 ## 目的 様々な観点からオブザーバビリティを改善する # 取り組んだ業務・実績 - ECS で動作するバッチの動作状況を可視化 - AWS の利用料金の通知 - VPC フローログを利用したネットワーク通信の可視化 - 自社ドメインの迷惑メール率を可視化 # 工夫した点 ## ECS で動作するバッチの動作状況を可視化 ### 課題 社内で利用されているほとんどバッチのアーキテクチャについて、EventBridge で ECS RunTask を実行する仕組みになっていました。このアーキテクチャの問題として、多種類のバッチを同一サービスで実行するのでバッチの種類ごとに実行時間やエラー率などを見ることが出来ず、バッチが正常に動作しているか非常に分かりづらいという点がありました。 ### 取り組み EventBridge から直接 ECS RunTask を実行するのではなく Step Functions を経由することで各種バッチのメトリクスを見られるようにしました。Step Functions を経由するだけでは各バッチのメトリクスを見ることが出来ませんが、ECS RunTask を実行する前に DynamoDB に実行するバッチの種類を示すパラメータと現在時刻を保存しておき、実行後に DynamoDB に保存した値を利用してバッチごとに実行時間、エラー率、起動回数を Cloudwatch で観測できる様にしました。また、Cloudwatch で作成した独自のメトリクスは Newrelic に送信してダッシュボードを作成することで、SRE チームで定期的に行っているパフォーマンス定点観測会（パフォ会）でも活用される様になりました。 ## AWS の利用料金の通知 ### 課題 ある機能をリリースしたときに外部との通信量が急激に増加してしまい平均使用量の約 10 倍の通信が発生していました。NAT Gateway を利用した構成における機能だったので通信料に比例して利用料金も急激に増加してしまいました。この事象にすぐに気付ける手段がなく1週間ほど利用料金が膨らんでしまう事象が発生してしまいました。 ### 取り組み AWS CostExplorer の API を Lambda から実行して利用料金のコストを取得し、Slack に投稿する仕組みを作成しました。日次の利用料金を前日比、先週比とともに全てのエンジニアが閲覧するチャンネルに投稿すること利用料金の急激な変化への気づきや、部署全体に利用料金の意識を持ってもらうことができました。 また、利用料金とは別にどんなネットワークの通信の変化があったか可視化する必要もあると考えました。いろいろ調査してみると利用中のオブザーバビリティツールである Newrelic に VPC フローログと連携して通信を可視化できる仕組みがあることを知りました。現在は PoC が完了した段階で本番環境への反映を検討中です。 ## 社内で利用する Lambda について ### 課題 `AWS の利用料金の通知` の課題解決において Lambda を利用しましたが、メインで扱う言語が PHP だったのでメンテナンスへのハードルを下げるために PHP で Lambda を実行できる環境を構築したいと考えました。 ### 取り組み Bref という技術を導入することで PHP で Lambda を開発できる環境を構築しました。Bref の利用には独自の概念の理解などが必要でデプロイが通常の PHP とは異なりますが、AWS SAM を利用しつつ Makefile でデプロイコマンドをまとめておくことで誰でも素早く Lambda へ反映できる様な仕組みも用意することが出来ました。

# プロジェクト概要 ## 目的 AWS を効果的に利用するための環境構築 ## チーム構成 1人 ## 担当した役割 - インフラ設計 - セキュリティリスク管理設計 # 工夫した点 ## セキュリティ、ガバナンス遵守のための環境構築 ### 課題 AWS の経験の少ない人などが AWS を触っていく上で、セキュリティリスクのあるインフラが作成されてしまったり、自身もセキュリティに深い理解があるわけではなくどういったものがベストプラクティスか分からないという点がありました。 ### 取り組み AWS から提供されている Control Tower を利用することで、AWS が提供するセキュリティのベストプラクティスを適応したり、SecurityHub や GuardDuty と連携することで問題を検知したら Slack に通知する様な環境を構築しました。CloudTrail などもセットアップされるため AWS 上での操作や変更も常に記録され、いつでも利用状況を把握することが出来ます。 ## CI/CD の構築 ### 課題 インフラの管理には Terraform を採用していますが、エンジニアそれぞれのマシンから変更差分を確認したりその反映を行うとなると、他の人が変更している修正とコンフリクトしてしまったり、Terraform が AWS リソースを作成するにはある程度の強権限を持たせる必要があるので、認証情報がそれぞれのマシンに一時的に保存されることになってしまいセキュリティリスクがあります。 ### 取り組み Atlantis という OSS を導入することでこれらの問題を解決しました。Github 上で Pull Request を作成すると Atlantis が自動でインフラの変更差分を Pull Request にコメントとして残してくれます。これらの差分が意図したものだとレビューされれば特定のコメントをすることで変更差分を AWS に適応してくれるので Atlantis のみが強権限を持てば良くなり、各マシンに AWS の認証情報が残る心配はなくなりました。 また、Atlantis には Pull Request をロックするという仕組みがあり、ある Pull Request がロックしている時は他の Pull Request が変更差分を適応することが出来ません。この仕組みによって複数人が Terraform を編集している時にお互いの Pull Request がお互いの変更差分を削除してしまう様な心配もありません。

# プロジェクト概要 ## 目的 既存サービスで問題になっていた部分の解決とスケーリング性能が高いバッチ実行システムの開発 ## チーム構成 1人 ## 担当した役割 - インフラ設計 - アプリケーション実装 - OSS 修正（コントリビュート予定） # 前提 本サービスの目的は、定期的なバッチ処理によって外部サービスから API を経由してデータを受け取り、別の社内サービスにデータを加工して横流しすることです。 # 工夫した点 ## スケーリング性能の向上 ### 課題 提供しているサービスにおいて、利用者が右肩上がりで増え続け、従来想定されていたより多くのリクエストを処理する必要があるサービスがありました。本サービスはバッチ処理をメインとしていますがその実行方法については直列的なものであり、あるユーザーの処理にスパイクが発生すると他のユーザーに影響が出てしまいます。 ### 取り組み 直列に実行している処理を並列にするとともに疎結合な仕組みを構築することにしました。 今まで定期的なバッチ処理によって外部サービスから情報を取得していたところを Webhook を利用し API Gateway と Lambda を利用してデータを取得することで、Lambda の同時実行数の増減で外部サービスからのデータ取得に対するスケーリング性能を向上させることが出来ました。しかしながら、受け付けたままの流量でリクエストを送信してしまうと取得したデータを送る先の社内サービスがその流量に耐えられない可能性があることを考慮し、入力のスケーリング性能に依存しない様に出力のスケーリング性能をコントロール出来る必要があると考えました。 AWS SQS や RabbitMQ、Apache Kafka など様々なキューサービスを検討した結果、Apache Pulsar が最も適していると結論付けました。本サービスは国内でのプラクティスがほとんどなく、公式のドキュメントを何度も見返したり海外の事例を参考にすることで現在は PoC がおおよそ完了し、必要な要件を満たす構築が実現できる見込みです。 ## Apache Pulsar の修正 ### 課題 Apache Pulsar の機能のひとつに Pulsar Function というものがありますが、ドキュメント通りの挙動が確認出来ませんでした。公式の Issue や Pull Request など様々な情報源を探ってみましたが解決には至りませんでした。 ### 取り組み OSS の中では比較的新しいということもありバグの可能性もあり得たので、関連機能の Pull Requests や Issues を確認しながらソースコードを読み進め、バグの原因を見つけることが出来ました。現在はバグ修正を行いローカル環境で意図通りの動作をすることが確認出来ていますが、OSS ということもあり今後は Pull Request を作成してコントリビュートしていきたいと考えています。