ID:17231さん

# 概要 開発リーダーとして 社内向け基幹業務システムに在庫の棚卸しのための機能の追加開発を行った 本プロジェクトは上場に向けて資産を正確に把握するために必要な機能で、かつ 年末の棚卸しに間にあわせるためにスピードとクオリティが求められていた # プロジェクトを成功に導くために スピードとクオリティが求められる一方で自分以外の開発メンバーが5人いたが gitに不慣れなメンバーや開発経験が浅いメンバーや入社して間もないメンバーがほとんどだったため 1次開発の失敗を生かして開発効率やシステムのクオリティをあげるために以下のことを行った 1. 1次開発時よりも時間をかけた詳細なロジック設計書を作成 - 実装者の実力や要件に関する知識の差による影響を最小限にするために - また、容易にN+1問題を潰せるようなDB設計を行った 2. ドキュメントは必要最低限のものに絞ってリンク集を作って集約 - ドキュメント作成や見る側の時間を短縮するために 3. システムの構成に関するドキュメント作成 - 入社間もないメンバーや途中でプロジェクトに参加する人が出てきた時にインプットの手間を省くため 4. ローカル開発環境の整備 - Dockerの設定が不完全で慣れてない人が構築に苦労する状態だったため 5. 事前に開発ルールを策定して周知 - 開発効率を上げるため - レビューがボトルネックにならないようにするため - コミュニケーションコストを減らすため - 不慣れなメンバーや途中参加のメンバーへのインプットの時間を省くため - など 詳細 https://qiita.com/rh_taro/items/b56cfab0fc4a84693b85 6. 自分は余力を残しつつレビューに徹した - 遅延が発生した際に自分の工数を使ってリカバリできるように - テストコードのレビューに特に注力してシステムの品質を上げるために 7. DBのロックの実装とそれに対するThreadを使用したテストに特に力を入れた - 数十人が一気に在庫をスキャンしていくためトランザクション周りの実装が甘いとデータ不整合が起きやすいため - 事前に調査してロックとロックのテストに関する資料などを集めておいた # 実装以降 フロントエンドを担当する予定だったメンバーが別タスクの割り込みで実装できなくなったため 急遽自分が担当することになった 余力を残していたおかげでリカバリすることができた また、Vue.jsの開発経験を積むことができた # 品質 レビューでテストコードに特に注力したため実装フェイズは遅延が発生したが テスト時に出たバグは数個程度で修正が少なかったためテストフェイズは前倒しで進み、 結果的に予定より早くリリースすることができ、リリース後もバグは0だった 実装時にテストコードに注力するとテスト以降のフェイズが楽になることを身をもって経験することができた # パフォーマンスチューニング 本プロジェクトでは - バッチの実行速度 - 棚卸し結果のCSV生成速度 の2点で時間がかかり過ぎていたため開発終盤で修正して高速化した ## Railsで書いたバッチ 当初12万件のデータを処理するために実行時間は1時間ほどかかっていたが、5分まで短縮することができた 行ったことは下記記事にまとめた https://qiita.com/rh_taro/items/eaec3e16248d88e2ccf9 バッチは在庫のテーブルをロックして棚卸しに必要なデータをまとめるため 「バッチ実行時間 = 在庫データの登録編集ができない時間」となり 業務影響が大きく、ユーザビリティ向上に大きく貢献できた ## 棚卸し結果のCSV生成 6万件ほどあったためCSVのダウンロードに2,3分かかっていたが 10秒程度まで短縮することができた ActiveRecordによる処理速度の遅さが原因だったため RailsのDB周りの処理を調べたりSQLの知見を生かして pluckメソッドや一部SQLを書いてActiveRecordを使わないように修正して高速化を実現した この機能も棚卸し実施中や実施後に いろんな部署の人がダウンロードして実施状況の確認や資料作成に使うため 業務影響が大きく、ユーザビリティ向上に大きく貢献できた

# プロジェクト概要 社内向け基幹業務システムの開発に実装フェーズから参加 サーバサイドはRailsでAPIを構築 フロントエンドはVue.jsでSPA ローカルの開発環境ではDocker(docker-compose) CircleCIで自動テスト/自動デプロイ SwaggerでAPI定義 Railsは未経験だったがPHPの経験はあったのでサーバサイドエンジニアとしてジョイン 終盤では一部フロントエンド(Vue.js)も担当 # サーバサイドエンジニアとして Railsは未経験だったがWebの知識は豊富で、既存ソースなどからのキャッチアップは得意なので ほとんど人に聞くことなく即戦力として割り振られたAPIを実装 初めて対応したチケットは軽微なものではあったが未経験だったrspecも含めて3日で対応し、 1ヶ月後には既存メンバーと同等のチケット消化スピードになった 3ヶ月後にはレビュアーとしての業務もこなすようになり、 4ヶ月後には開発リーダとして二次開発に参加した 自分が参加した時点でプロジェクトは遅延していたが上場のために納期を伸ばすことができず 速度重視での開発になっていたため、テストフェイズやリリース後のバグ発生率が非常に高く リリースは納期に間に合ったが「成功」とは言えないプロジェクトだった これにより雑なテストコードや無茶なスケジュールで実装をして スケジュールとして間にあわせることができても後々バグが大量に発生してテストフェイズで結局遅延することを身をもって体感することができた また、Rails/rspec/docker/swagger/ci/vue.js/AWSなど いずれも初めて触るものだったがこのプロジェクトを通して今時の開発を一気に身につけ大きく成長することができた パフォーマンスチューニングやSQLは昔から好きだったので Railsで起こりがちなN+1問題の修正をしてアプリケーション全体のパフォーマンス向上に大きく貢献した

# 既存環境の整備 入社直後に真っ先に行ったのはRailsのローカルの開発環境のdocker化 credentialを置くだけでawscliが使えるdocker環境も用意 ローカルにrubyやmysqlなどを入れるのが嫌いなのと環境構築に無駄に時間を取られないようにするために AWS周りでは EC2のログによるストレージの逼迫に対応するためにCloudWatchLogsの導入とログローテートを設定 併せてメモリ使用量のメトリクスをCloudWatchに流してメモリ使用率が高い時にslackへ通知するよう設定 # コスト削減 RDSのリードレプリカがRedashからしか使ってないのに巨大なインスタンスになっていたので小さくして月間$2000削減 # アプリケーション実行環境のリプレイス(EC2からFargateへ) productionとstagingが同じになっていたVPCを分けて再構築 サブネットもすべてパブリックサブネットになっていたのでプライベートとパブリックを用意し RDSやRedisなどをプライベートサブネット配下に配置しELBと踏み台用のEC2のみ用意 そして、EC2上で実行していたRailsアプリケーションをFargateへリプレイス 手動でsshして各インスタンスへCapistranoでデプロイしていたフローを CircleCI/S3/CodePipeline/CodeBuild/CodeDeployを使って自動デプロイ(Blue/Green)を構築 デプロイの成否をlambdaからslackへ通知 また、Fargateはsshできないため`rails console`などを使える環境として単一コンテナのElasticBeanstalk環境を用意 EBも同様に自動デプロイ その後terraformを導入してインフラをコードで管理 # その他工夫 CodeBuildでdockerイメージのビルドを高速化できるようにキャッシュを有効化 また、キャッシュが適切に使えるようにdockerfile内でインストールするパッケージすべてにバージョンを明記して冪等性を持たせた CloudWatchでのログが見やすくなるようにdockerイメージは同一でもECSのタスク定義を別々にした(DBマイグレーションやrakeなど) dockerの運用時にコンテナはステートレスであるべきだが rake(コマンド)などを実行した場合の成果物を残せるようにS3に保存する仕組みを用意

# 概要 LAPP(CentOS7、Apache2.4、PHP5.6、PostgreSQL9.6)環境で クロスワープ社のMODD ECMというショッピングカートシステムを用いて アーティストのグッズ販売をするECサイトの構築をしました。 PHPのテンプレートエンジンにはSmartyを使用しました。 チームメンバーはディレクター1名、デザイナー1名、エンジニア1名。 # 詳細 ### インフラ ApacheのバーチャルホストやDNSのZone設定から運用/保守まで1人で行っています。 SSLの設定についても暗号化スイートの設定を見直して SSL LabsというサービスでAランクを取れるまで試行錯誤しました。 ### アプリケーション構築 サイトのベースとなる部分はすでに社内にあり、流用した部分は多くありましたがそのままで終わらせず クライアントの要望に合わせて同アーティストのオフィシャルサイトにも一部のグッズを表示できるようオフィシャルサイト側とCMSを改修しました。 ソースコードについても不要な関数の削除や繰り返されている同じ処理の関数化など 可読性や再利用性の高いソースになるようリファクタリングも欠かさず行ないました。 ### 負荷対策 処理速度向上のためにnewrelicやApache Benchを用いて性能テストを行い、 PHP側で行なっていたループによるデータの整形処理をテンプレートエンジン側のループへ統一したり SaaSのAPIを利用した会員認証処理で使われていたSOAP通信のライブラリの読み込みで 大幅に処理が遅くなっていたためWebAPIを使用するように会員認証処理を改修しました。 他にもDBへのコネクション数を減らすためにSQLで取得したデータをmemcachedの利用、 apacheのプロセス数の上昇を抑えるために画像やcss、jsファイルなどの静的ファイルをAWSのS3へ配置、 可用性の向上にも務めました。 オープンは2017/06で制作期間は1ヶ月半ほどでしたが、現在も継続して運用中です すでにオープンしている他のECサイトへもアクセス対策を講じたり memcachedの更なるパフォーマンス向上のために UNIXドメインソケットによる接続の検証なども行なっています。 # その他 他にもECサイトを1つ、合計2つのECサイト構築を経験しました

# 概要 LAPP(CentOS7、Apache2.4、PHP5.6、PostgreSQL9.6)環境で 月額制のアーティストのモバイルファンクラブサイトの構築を行いました PHPのテンプレートエンジンにはSmartyを使用しました。 チームメンバーはディレクター1名、デザイナー1名、フロントエンドエンジニア1名、バックエンドエンジニア1名。 # 詳細 ### アプリケーション構築 アーティスト本人のこだわりにより独特な世界観の強い案件で、ユーザがプロフィールで設定したキャラクターによってサイトのデザインや表示を変えるという社内で初の試みがあったが仕様は不確定な部分が多く、 チームメンバーやクライアントとこまめに情報共有・確認を行い可能な限り仕様を詰めて どうしても決まらない部分についてはその時点での構想を全部踏襲しDBの構造やアプリケーションを汎用的に設計・構築することでサイトオープン直前や直後の仕様変更にもスムーズに対応することができました。 また、デザイナーやアーティスト本人のイメージする世界観を実現するためにURLにまでこだわりサイトの構築を行いました。 課金方式はキャリア(docomo、au、softbank)決済サービスと決済代行サービスによるクレジットカード決済を導入しました。クレジットカード決済についてはカード情報の非通過化に対応しました。 クレジットカード決済については決済代行サービスの仕様書にあったJavaScriptのソースではAndroid4系のブラウザで動作せず、調査したところイベントハンドラが比較的新しいもので古いブラウザが対応していない可能性に気づき、別のイベントハンドラを代用することでAndroid4系のブラウザでも決済が可能になるようにしました。 ### E2Eテスト自動化 puppeterというHeadless ChromeのNode APIライブラリを使用して サイトへの入会、決済、ログイン、退会などの重要かつ時間のかかる部分のテスト自動化を行い テストの工数削減を行いました。 ### 負荷対策 モバイルサイトでも同様に、ユーザごとに表示が変わらないコンテンツはDBから取得したデータをmemcachedでキャッシュする負荷対策を実施しました サーバのトラフィックの増加対策にはコストパフォーマンスやファイルの同期の時差の面からS3ではなくCDNを使用しました。 # その他 他にもモバイルサイトを2つ、合計3つのモバイルサイト構築を経験しました。

# 概要 LAPP(CentOS7、Apache2.4、PHP5.6、PostgreSQL9.6)環境で アーティストのオフィシャルサイトの構築を行いました。 PHPのテンプレートエンジンにはSmartyを使用しました。 チームメンバーはディレクター1名、デザイナー1名、エンジニア1名。 繁忙期の中で同一アーティストのECサイト、モバイルサイト、オフィシャルサイトの3サイトを同時でオープンすることになり、メイン担当者がEC・モバイルサイトを担当し自分がヘルプとしてオフィシャルサイトを担当しました。 # 詳細 ### アプリケーション構築 このサイトではアーティスト本人のSNSの投稿と所属事務所のサイト上のニュースをオフィシャル・モバイルサイト上でも表示したいという特殊な要望があり、モバイルサイト担当者のエンジニアと相談しつつ共通でAPIでデータを取り込むバッチを作成し、サイト上で表示できるようにそれぞれ実装しました。 また、アーティスト本人がCMSを通さずメールでサイトにブログをアップしたいという要望があり メール投稿のシステムは社内にすでにありましたが、htmlメールに対応しておらず運用上の制限があったため マルチパートの処理の強化、階層化されている場合には再帰的にパースする処理を追加してhtmlメールにも対応させることができました。 ### 負荷対策 CNAMEレコードにCDNのドメインを設定してサイト全体をCDN化していました。 そのためサイトのオープン直後のアクセス集中(1時間あたり54000PV)でも表示が遅くなったりすることはありませんでした。 ### 緊急対応 サイト公開時には非公開のオリジンのドメインが公開されてしまい、一時的にサーバへの負荷が高くなったが すぐにhtaccessでCDN以外のアクセスを公開ドメインにリダイレクトさせるように対応してことなきを得ました。 # その他 オフィシャルサイトは他社運営の既存サイトから同一ドメインでの移管だったため あらかじめ既存サイトのDNSのTTLを短くしておき、切り替え後DNS浸透までの間は新サイトではメンテナンス表示にしておくことで問題なく移管させることができました。 他にもオフィシャルサイトを3つ、合計4つのオフィシャルサイト構築を経験しました

# 概要 運営しているサイトのカスタマーサポート対応をしています。 サイト数が多いためphp5.2〜7.2のサイトが対象で、「ログイン・会員登録できない」「コンテンツが見れない」といったユーザからのお問い合わせに対してカスタマーサポート対応の担当者だけで解決できない問題の調査・対応します。 # 詳細 アプリケーションログ、アクセスログなどからユーザの挙動や使用している端末、 メールアドレスなどからDB内の会員の登録状態や決済の状況などを調査し、必要に応じてデータの修正します。 ユーザ自身も登録情報が曖昧な場合がありそういったケースでは登録情報の特定が困難なため カスタマーサポートスタッフを通してユーザへヒアリングをして断片的な情報をつなぎ合わせて会員情報を特定します。 決済周りで問題が起きていそうな際にはアクセスログからユーザの挙動を再現し ソースコードや決済サービスの仕様書を読んだり決済サービスの窓口へ問い合わせもします。 自分一人では原因が究明できない場合にはエンジニアチーム内で共有し他のエンジニアを巻き込んで調査を行います。 エンジニアだけで判断できない問題についてはディレクターやカスタマーサポートスタッフの判断を仰ぎ、対応します。 また、自分が構築したサイトではないサイトを調査することも多く、構築を担当したエンジニアに聞いたり 社内のwikiやソースコードを読んで処理の流れや仕様を調べてから調査を行います。