振り返り
やりたい
- 設計と実装に集中
- 設計と実装の半々が技術者としてバランス良いと考えています
- 非機能要件、パフォーマンス・アーキテクチャ設計技術の向上。そこにバックエンド技術者としての腕が出るから
強み
- 創業メンバーだった１社目は顧客対応含め背伸びして泥臭くやっていました。あくまでベースは技術者ですが、ベンダーコントロール、打ち合わせや要件定義、課題抽出から解決提案とかも好きで。前職のお客様方にも退職後に連絡を頂いてファンになって頂いている信頼を得られているのは強みかなと思います。
目指したい
- プレイングマネージャ
- バックエンドアーキテクチャ設計のスペシャリスト
性格診断・適性検査 結果
2014年
システム保守会社の創業メンバーとして参画
最初の１年半は社長と2人で、軌道に乗るまで5年間エンジニアとして従事、ネットワークやサーバミドルウェアのパラメータだけでなくプログラミングができてシステム全体の保守ができること。更にセキュリティを合わせ。お客様のクラウド、WEBサービスの保守に参画し、複数案件に対してお客様と対面やChatツールを駆使し、ときには会食など密に折衝し直接やりとりしながら、システム保守を行なってきました。
社内の仕組みづくり。会社のホームページ、SEO対策から、SNSマーケティングによる仕事の獲得。自身の学んだ技術を商品化し外部に売り込み、お客様に満足して頂くことで継続保守を行える経験ができました。
零細企業だったこともあり、様々な案件に対して１人称で参画できました。会社を安定軌道する為に様々な取り組みを積極的に全力で行なってきましたが、会社の体制も整い安定期に入ったことで開発を主として行いたいという気持ちが強くなり転職に至りました。
2019年9月
アプリ会社にテクニカルエンジニアとして転職。
国内開発事業部という受託部門に配属。
【イベント施設向け会員アプリ開発にてバックエンドを担当】
【チーム構成】
デザイナー２名、バックエンド3名、iOS, Androidエンジニア3名(SE兼任)、PM1名、ディレクター2名、統括1名
【業務内容】
- SwaggerによるAPI設計・Laravelによる実装
- MySQL WorkBenchを利用したER図作成
- 設計書作成
【言語/インフラ/ツールなど】
AWS EC2, Amazon Linux2, RDS, CloudFront, ALB, S3による基本構成。GitLab CI/CD, PHP7, Laravel, MySQL, phpMyAdmin, MySQL WorkBenchによるDB設計とAPI実装。Swagger OpenAPI, RedocによるAPIドキュメント, JWTを利用したアクセス、リフレッシュトークンによるログイン。
【発揮したバリュー】
- システムエンジニアとして要件のヒアリングや仕様設計
- バックエンドエンジニアとしての詳細設計と実装
API設計、DB設計を行い、0からモバイルアプリに必要なAPI開発を行う経験ができました。JWTによるログインの実装は良い経験でした。度重なる仕様変更によるやり直しにも粘り強く対応できました。
XDであるデザインからアプリエンジニアと協議しながらAPIやDB設計を行えました。
【IoT関連サービス技術検証の代行】
【チーム構成】
バックエンド2名、SE2名、PM1名、ディレクター2名
【業務内容】
クライアント企業様のRFID関連サービスのAWS IoT関連の技術研究案件
【言語/インフラ/ツールなど】
AWS EC2 -> IoT Core, -> SQS -> EC2 -> DynamoDB, Ubuntu, RDS
【発揮したバリュー】
AWSに知見があるということで参画しました。2日だけの参画でしたが短期で目的のアウトプットを出せてよかったです。
【社内IT部門 技術戦略本部に兼任】
この頃社内IT管理部署にも所属し、社内システムの改修やサーバの保守、ネットワーク。社内向け勉強会の開催などを主催。
【社内向け工数管理システムにてバックエンドを担当】
【チーム構成】
デザイナー1名、バックエンド・フロントエンド3名、PM2名
【業務内容】
WEBアプリである既存システムの改修。バックエンドとフロントを担当、システムの管理画面とフロント両方を担当。改善要望に応える為に積極的に舵をとって取り組みました。
改修のDB設計は元開発者が行いましたが、途中から設計を引き継ぎ対応しました。
【言語/インフラ/ツールなど】
AWS EC2, Amazon Linux2, Route53, GitLab CI/CD, PHP7, Laravel, MySQL, jQuery, phpMyAdmin
【発揮したバリュー】
バックエンドとフロントの古き良きWEBアプリ開発の改修案件。社内向けの簡易な仕様書とデザインから仕様を読み取り、実装を行う経験をすることができました。リーダーという肩書きではありませんでしたが、積極的にチームをひっぱりスケジュール通りに納品するよう励ましながら進めました。ただ納品１ヶ月前に自社サービス部門へ部署異動となりました🐱💦
- コードレビュー
- 重い処理の解決
2020年7月
自社サービス開発部署に配属、兼任として全社的にインフラを統括するインフラセクションにも配属。
私はインフラ技術の平準化をミッションとして取り組む。
【自社サービスのイベント支援WEBサービス改修 ver1.10にてバックエンドを担当】
【チーム構成】
デザイナー1名、バックエンド3名、フロントエンド3名、アプリエンジニア1名、リーダー1名、PM1名、グロースエンジニア1名、営業・ディレクター12名、事業部長1名、ブリッジエンジニア1名、海外子会社１社
【業務内容】
自社の主力商品のバックエンド開発に参画。
Firebaseに連携する為のモジュールの開発を主に行うことで、既存サービスや設計を学ぶことができました。数十のモジュールで構成されており、ポリモーフィズムといったオブジェクト思考やデザインパターンが多用されており、品質の高いサービス。会社の主力サービスに携われることとても光栄に感じています。
また動画投稿を行えるように既存モジュールや関連APIに関する改修をフロントと協議しながら設計し、実装しました。
【言語/インフラ/ツールなど】
AWS EC2, ALB, CloudFront, S3, ElastiCache(Redis), RDSによるAutoScaling基本構成。 CloudWatch Logs, CloudWatch Agentによるログ集約。 AWS WAF, WAF Charm CloudFrontによるWAFとキャッシュ。 Lambda, SNS, CloudWatch Logs Slackによる閾値通知設計と実装。Laravel Job, SQS, SESによるメール送信。APIによるマイクロサービス。Lambda, Kinesis, S3によるログのエクスポート。Route53, ACMによる証明書更新とルーティング。GitLab CI/CDによるチーム開発。PHP7, Laravel, MySQL, Swagger, RedocによるバックエンドAPI開発。MySQL WorkBenchによるDB管理。Firebase Hosting, RealtimeDB, Cloud Functions, AWS Lambda, API Gateway, Python, node.jsによるサーバレスサイト。Cloud Trailによる監査。npm Forever, Vue.js, Nuxt.js, Vue Cliによるフロントコーディングの読解。 Vagrant, Dockerによる開発環境。 Nginx, PHP-FPM, Linux Kernelによるパラメータチューニング。Ubuntu, JMeterとデバッグ、各ログによる障害解析。CloudWatchによるモニタリングによるパフォーマンスとセキュリティ分析とセキュリティ対応策定。
●リモートによる開発
- チケット…Wrike
- ChatOps … Slack(通知、障害通知)
- DevOps … GitLab, Soucetree, Slack
- テレビ会議 … Google Meet
- ドキュメント … Confluence, Google スプレッドシート, Google Drive, Keynote
アジャイル開発。コロナ禍により週1の出勤日以外はリモートによる開発
●API開発
- デバッグ … Postman, Linux Curlコマンド
- JSON整形ツール … JSONきれい,
- DB GUI管理 … MySQL Workbench, phpMyAdmin
- コーディング … VS Code
- ローカル … Vagrant, Docker
【本番のみ】
■DNS ・Route53 + ACM ■ルーティング ・CloudFront 3台 ・BehaviorによるS3, ALBへのルーティングとキャッシュ ・AWS Sheild + ACMにWAF Charm適用 ・ALB 4台(プロキシ, API, WEB, 認証) ■プロキシサーバ・ALB 4台(プロキシ, API, WEB, 認証) ・*.sample.tokyoでの*であるクライアント名による処理をしてAPIサーバにアクセスを渡す ●EC2(Nginx reverseproxy) ・t2.xlarge 1台 ■API, 管理コンソールサーバ ●EC2 ・t2.xlarge 20台 ●RDS ・db.m5.8xlarge 1台 ●ElastiCache(Redis) ●キャッシュとセッションをストレージ ・シャード1, ノード2 cache.r4.2xlarge // cache.r4.xlargeで障害が発生した。原因はスペック不足(ネットワーク帯域性能限界、CPU・メモリの処理能力を超えてSWAPの発生により更なる処理低下) primary 1台 replica 1台 ■WEBサーバ ●EC2 ・t2.xlarge 1台 ●RDS ・db.t3.micro 1台 ■認証サーバ ●EC2 ・t3.medium 1台 ●RDS ・db.t3.micro 1台 ■ジョブサーバ ●LiveMapの画像生成 ●メール ・APIサーバでAWS SQSに投げたキューをポーリングしてBounce, ComplaintとしてアドレスがDBに登録されていないかをフィルタリングしてSESへメール ・APIサーバEC2 -> AWS SQS ・ジョブサーバEC2 -> ポリーング AWS SQS ・ジョブサーバEC2 -> SES ●EC2 ・t2.xlarge 1台 ■アナウンスページ ・フロント Firebase Hosting ・バックエンド Firebase CloudFunctions <-> API Gateway -> Lambda -> CloudWachLogs, EC2 Firebase CloudFunctions -> RealtimeDB ■ログ ・EC2 EC2(CloudWatch Agent) -> CloudWatch Logs -> S3 ・CloudFront CloudFront -> S3 ・WAF Charm CloudFront -> AWS Shield ACM(WAF Charm Rule) -> Kinesis -> S3 ■監視 ●アラート ・CloudWatch Alarm -> SNS -> Lambda -> Slack ●アラート ・CloudWatch Alarm -> SNS -> Lambda -> Slack ・社内+クライアントSlackチャンネル ・社内オンリーSlackチャンネル ●モニタリング ・CloudWatch Metrics
【発揮したバリュー】
アジャイル開発の中で新規モジュール開発、既存モジュール仕様変更による関連APIの改修を行いました。初期メンバーの設計、バージョンアップにより高収益をあげる品質の高い主力製品に開発者として参加できたこと光栄でした。仕様変更による本番データへのデータマイグレーションではローカルでデバッグを入念に行い、devサーバ、ステージング、本番へと対応できました。
全案件で取り扱っていたAWS SESの実装のサンプルコードや注意点など共有しました。朝にも及ぶ粘り強いインシデントへの対応や改善を評価して頂き前職のインフラエンジニアの経験が生きてSRE的な動きが増えてきました。エンジニア役員２人に頼られ、社長による「頼られる人間になってください」という言葉への大幅なコミットができました。
CloudWatch Agentによるログ集約
オートスケール 構成で散らばっていたEC2のログをCloudWatch Logsにてログ集約を実現
アラート通知の構築
CloudWatch Alarm -> SNS -> Lambda -> Slackによる通知機能を実装。
アラート通知の閾値を設計して実装しました。
ドキュメントの整備
開発者向けのドキュメントが不十分であった。参画して理解に苦労した部分について、率先し企業内WikiであるConfluenceにドキュメントの整備をはじめた。自分が実装したものについての手順や、インフラ運用についてもドキュメントを記し、チーム内にドキュメントを整備する流れが強まった。
イベント時の大量アクセス時の対応
- AutoScalingのスケジュール化を提言。休みの日に出勤する必要がなくなりました。
国内最大級のイベントにてスパイクによる大規模障害が発生
ElastiCacheのスペック不足であることをデバッグログとJMeterによりキャッシュ箇所で処理が詰まっていることを特定。 CloudWatchのメトリクスよりSWAP発生を確認することで更に仮説を強めた。そしてJMeterによる障害再現により、全体スペックの不足から障害発生と特定。cache.r4.xlargeからcache.r4.2xlargeへの変更により、スペックとネットワーク帯域の高いインスタンスに変更することでサービス継続することが可能になった。
RDSの障害
SWAPが発生していた為スペックをあげることにより対応
メールが不正送信するインシデントの発生
バウンスレート、苦情率の急上昇を発生開始日にモニタリングから上長に報告し大事になることを未然に不正だ。深夜であるがCTOと共に対応の策定を行いました。SESのNotificationsによりスパムメールの踏み台にされていることが判明、Cloud Trailにより使い回していたIAMユーザの特定に繋がった。対応としてIAMのアクセスキーを交換し、セキュリティ体制を整えることを行いました。CloudWatch+SNSによるSlackへの閾値設計を提案し実装。
運用ノウハウの積極的共有
RDSで小さいインスタンスを利用している機能があり、その負荷分散にマスター・リード構成にしたいという案が出た際の提言
WAF Charmの試験導入後のモニタリング
ステージングに試験的に設置しているWAF Charmの攻撃検知率が低いので、
こういう仕様なのか、設定が甘いのかサポートに確認。
アクセスログからほとんどの攻撃がWAF Charmを貫通してアプリケーションサーバに届いていることを確認。
よくある攻撃例。 OSコマンドインジェクション、リクエストやパラメータによるインジェクション攻撃、DB管理アプリ・Tomcatなどの管理ページ・コンフィグ・環境変数ファイル探索、不正ログイン・ブルートフォース、CMSやフレームワーク等既知の脆弱性を狙ったもの、ルータの脆弱性を利用したサーバへの攻撃(/tmpにWEBシェルを仕込んでリモートからサーバ不正操作を意図)などなど
プログラミングによるモジュール追加・改修だけなく。パフォーマンスチューニング、インジェクションの分析、セキュリティ設計などSRE的な役割も多くなってきました。
7月に異動してきたばかりですが、積極的な動きからレベルの高いチームの方達にもメンバーの一員として認められてきたように感じています。
サーバレスによるサービスステータスページ作成
・フロント Firebase Hosting ・バックエンド Firebase CloudFunctions <-> API Gateway -> Lambda -> CloudWachLogs(EC2, RDS, ELB) Firebase CloudFunctions -> RealtimeDB
サーバレス構成でEC2, RDS, ELBのステータスを取得し、稼働状況を表示するページの作成。
JavaScript, PythonによるAWS Lambda, CloudFunctionsの作成に対して問題なく対処できる。
ガヤとしての貢献
PMがメンバー全員にうなぎをご馳走すると予約したと提案してくれたときに、「うなぎぐらいで喜ばねぇぜ」ｔってメンバーが素直になれないスカしたムーブを行なったことによるシーンとした無音空間が発生、その際に迅速に誰よりも「おおー！うなぎだ、やったね。うなうなと」喜んでPMを助け、あっ喜んで良いんだってチームに安心感を与えチームの温度を高めることに貢献🐱✨
気づき
- 初期設計の段階で多言語化して海外展開も視野に入れたアプリかどうかは大事
多言語切り替え対応のアプリであり、多言語に対応するデータ構造を後から追加開発で拡張するのはハードに感じる為
秘伝のマイグレーションを継承
2020年10月13日〜
【自社サービスのイベント支援WEBサービス改修 ver1.11にてバックエンドを担当】
【チーム構成】
デザイナー1名、バックエンド3名、フロントエンド3名、アプリエンジニア1名、リーダー1名、PM1名、ブリッジエンジニア1名、グロースエンジニアリーダー1名、営業・ディレクター10名、事業部長1名
【業務内容】
既存機能の設計・実装
- タスク見積もり
- APIドキュメント
- ダッシュボードAPIの実装
- ブース出展機能の設定画面拡張
・簡単LIVE配信
・マッチングチャット - リリース後の不具合切り分け
インフラからアプリケーション、クライアント - カスタマーサクセスからの問い合わせ・不具合報告からの技術対応
- CI/CD管理
- エラーハンドリングの追加
会員向けの交流機能ダッシュボード設計・実装
・オンラインChatでのチャットメッセージ未読メッセージ通知処理
APIサーバ ・チャット送信 -> Redisに未読メッセージメタ情報格納(user_id, message_id, 送信日時など) バッチサーバ ・Redisの未読メッセージメタ情報を取得してAWS SQSに登録 ジョブサーバ ・AWS SQSを監視してメール実行
【エラーハンドリングの追加】
【CI/CD管理引き継ぎ対応】
AWS SES メール送信設計での間違った実装の指摘
- Bounce以外にCompalintも処理をしないといけないが。未実装な為その間違いを指摘して直して貰うように提言
JMeterを利用した認証認可サーバの負荷試験 + キャパシティプランニング・チューニング
- ログインのAPIを叩いてトークン取得するAPI
- トークンを利用して更新処理するAPI
これにおいて、JMeter５台を用いた負荷試験を行い、サーバのスペックアップに、エラーをログとAPIのエラーハンドリングから1つず潰してからチューニングを行った。
Nginx+PHP-FPMチューニング worker_connections are not enough while connecting to upstream
- EC2: c5a.2xlargeに変更
設計
- DB定義、API設計書の作成
・ブース出展者機能、ブース出展管理者ダッシュボードの新規
・既存モジュールの改修 - 仕様書からWBSの作成とWrikeへのチケット割り振り
実装
- APIの実装
●できたもの
NoSQLによる負荷防止対応
- 訪問者数履歴を一時的にNoSQL Redisに保持し、Redisに保持したデータをバルクインサートコマンドを実装しLaravelのスケジュールにて5分毎に実行することで負荷軽減を行なった。
既存システム構成の誤った実装の指摘と知見共有
既存のシステムにおいて、
揮発性のRedisに決済に絡むトランザクションデータの一部を一時データとして保管していることが判明。チーム内Slack、開発チームMTGでの口頭で提言しました。
インフラセクション
- バラバラで管理されていない証明書管理を提言。
- Wifiルータの障害切り分けと改善提案
・Wifiルータを増設することでネットワーク障害対応提案と実施
既存の構成は1つのWifiに100台近いデバイスが接続する形で、接続障害が発生していました。
セオリー通りに1つのWifiに対して30デバイス以下になるように、Wifiを増設し席の配置に合わせて接続して頂くようアナウンスしました。
→安定稼働🐱✨
2021年1月12日〜
【自社サービスのイベント支援WEBサービス改修 ver1.11.5にてバックエンドを担当】
【業務内容】
- Live配信の配信料履歴バッチ
Tencent Cloud APIを利用してアップロード、ダウンロード通信量を集計し履歴に保存を行うバッチ集計 - 集計・管理画面のAPIの設計と実装
Live配信での配信量の統計データを - 集計・管理画面のAPIで取得するバッチの設計と実装
Tencent Cloud APIからLive配信で利用したデータを取得し集計 - 次期プロジェクトで開発するソーシャルログインモジュール技術調査
OpenId Implicit Flow
【Live配信の配信料履歴バッチ】
- 当初Tencent Cloudの仕様上存在しないAPIが一部あり、要件が満たせなかった。
→
Slack上でTencent Cloudサポートとやりとりさせて頂き必要なAPIを用意して頂き要件を満たせた。
- ブース出展機能のCSVアップロードするとデータが壊れる課題が浮き彫りに
CSVアップロード実装者が、仕様であるバリデーションをコードから読み取ることが難しいのが原因。CSVアップロードする時にはバリデーションがを事実上確認しにくい。作るのが難しい状態が問題。
一部のトランザクションデータだけをみてCSVでデータ投入することで、システムが壊れる事象が発生。CSVアップロード時からJSONを組み立てるが、そのJSONにバリデーションがかかっていないことが問題。正解のデータ はコントローラのリクエストとValidaterで定義されている。バリデーション = 仕様であるが、CSVアップロード時の実装者が仕様を把握できない仕組みになっている。また別の中間テーブルとの紐付きが必要な箇所もある。
問題解決の検討案
- CSVアップロード時にもバリデーションを通す
・CSVアップロードしたデータが正しいことを保証する仕組み。CSVアップロードしたデータが正しいことをコード上、またはドキュメントからわからないと正しくCSVアップロードは実装できない。
・バリデーションを通す為には、
CSVアップロードを実装する為に正しいJSONの形 or データの定義を知らなければならない。
・DDD(今更？)。DDDのValue Object
https://qiita.com/mejileben/items/302a9f502ca0801b1efb
・ドキュメント
→
私が引き継いでバリデーションを忠実に実装して対応。
2021年02月03日〜
【自社サービスのイベント支援WEBサービス改修 ver2.0にてバックエンドを担当】
【業務内容】
2.0は改善プロジェクト。フロントチームと調整しながらAPI設計、実装。AWS側設定。
- CI/CD管理の引き継ぎ
前任者が退職による引き継ぎ管理対応 - CI/CDパイプラインの追加
- AWS SES 送信元設定メールアドレスの自動設定登録・削除
詳細・API設計。実装。削除ジョブで失敗ステータス時にSlackに通知。
Laravel Job, Queue, queue worker, Supervisor, AWS SQS, AWS SES API, Slack WebHook - 送信元メールアドレスと既存モジュールの紐付け
- チケットモジュール 下書き・本番昇格機能改修
- 会員管理の一括系処理 実装・シーケンス図作成(ツール)
・APP API, 認証・認可サーバAPI連携
・会員情報+マイページモジュール連携でのリストCSV エクスポート(Response, SqlFileObject)
・CSVとジョブによる一括新規登録・更新
1. APIサーバ-> AWS S3にCSVアップロード・SQSへキュー発行
2. ジョブサーバ -> キューをポーリング、CSVをS3から読み込む
3. ジョブサーバ (更新用リクエスト生成)-> 認証サーバ (更新)
4. ジョブサーバ ← 認証サーバ (認証側DBの会員登録実行処理のtrue, false返却)
5. ジョブサーバ
trueの場合にAPI側DBの会員新規登録処理 - 会員情報更新 プロフィールモジュール CSVによる一括更新の改修
- チケットモジュールの改修
- 顧客管理画面のIPアクセス制限管理機能・ミドルウェア作成
- ブースモジュールLive配信の視聴履歴ダウンロード可否プロパティ追加
- カスタマーサクセスからの問い合わせ 復旧対応
- DATADOG採用検討・ベンダーMTG
- 課題の抽出と解決提案
コンソールで管理ユーザの送信元メールアドレスをお客様側でも複数自由に選択できるようにする機能追加
- 顧客 -> 管理画面で送信元メールアドレスを登録
- 管理画面 -> APIサーバ -> ジョブ ::dispatch()
- 顧客はメールがメール認証が届くのを待つ。メール認証のリンクをクリック
- 10秒程度で管理画面の送信元メールアドレスがVerifyになる
- 顧客管理画面 -> Laravel API (JOB::dispatch)-> AWS SQS <- supervisor(Laravel Worker) -> Laravel JOB <-> AWS API
[
'VerificationAttributes' => [
'' => [
'VerificationStatus' => 'Pending|Success|Failed|TemporaryFailure|NotStarted',
'VerificationToken' => '',
],
// ...
],
]
認証待ちなどあるので、VerificationStatusのステータスの値を見ながらジョブのStatus毎に処理を切り替えていき、顧客の処理状況とSESのStatusをチェックしながら非同期でディレイをかけながら調整する。
利用API
- AWS SES getIdentityVerificationAttributes
- AWS SES verifyEmailIdentity
Jobs\Client\
- VerifySendMailJob.php
handle()でProcessServiceを回す。ジョブのステータスを記録しつつ、保守性が高い構造で実装
Services\VerifySendMailJob\
- RegisterService.php
コントローラがRegisterServiceを利用して初期設定しVerifySendMailJobをディスパッチする - ProcessService.php
プロセスを管理してStatusを更新していく - SesService.php
AWS SES APIを管轄する
またリポジトリパターンでModelであるEntityにStatusを定義し、更新処理をリポジトリに持たせ抽象化する
【AWS GuardDuty, Detectiveを利用した不正APIコール調査】
GuardDutyのSlacke通知からDetectiveを利用して原因調査。
【会員情報更新 プロフィールモジュール CSVによる一括変更】
プロフィールモジュールは汎用的、拡張的な構成になっているので、
例として同じ住所.都道府県でもn個存在する構成になっている。
それらに合わせてバリデーション、更新処理を汎用化させることで対応。
"都道府県\n key=xxxxxx&&method=ADDRESS&&option=prefecture&&share_profile_id=999&&keys=null&&values=null"
CSVのヘッダーには このようにパラメータを持たせることで、ヘッダーの位置が変わってもそれぞれ更新できるようにした。
【CSVによる会員登録・更新処理の非機能要件対応】
20,000件の処理性能が定義された。
- ジョブサーバのキャパシティプランニング
CPUが100%で張り付いており、ロードアベレージ 25。同時処理のジョブが多く処理遅延が発生していた。
同時処理をできるようにCPU性能が高いインスタンスに変更
t2.largeをc5.2xlargeに変更(34,712円/月)に変更 - Nginx, PHP-FPM, CloudFrontの設定値を更新し対応
- Nginx
# vi /etc/nginx/nginx.conf
http {
+ client_max_body_size 50m;
- PHP
# vi /etc/php/7.3/cli/php.ini - post_max_size = 8M + ;post_max_size = 8M + post_max_size = 50M
- CloudFront
Origin and Origin Groups
・ELBのところで、Origin Response Timeout 10 -> 60に変更
20,000件でCloudFront側で504エラーが再発。
60秒以上はコンソールからはできないので代理店に伸ばせないか問い合わせ。
●出来たもの
【CI/CDの改修】
NUXTがビルドしきる前にロードバランサーに紐づくなど問題があった。
- フロント用のNuxt SSRアプリケーションのCI/CDをBlue/Greenライクに改修
- ヘルスチェックの見直し。CI/CDでのビルドが正常に行われたことを確認してから次のジョブ に進むようにした
【DATADOG採用検討・ベンダーMTG】
- DATADOGの導入検討、DATADOGセールエンジニアと費用対効果など合わせて検討を行なった。
https://www.datadoghq.com/ja/
【課題の抽出と解決提案】
事業部・開発チームがかかえる課題を19個抽出してWrikeに記載
- 仕様を検索できないので、バグなのか仕様なのかわからないことでCSから問い合わせが発生している
技術者もソースコードを見て確認しないといけないので１時間〜半日工数がかかっている
→検索できるようにする - サーバの正常系を管理できていない。
何をもってしてそのサーバが正常動作しているかという点// 例えば、xxxサーバをアップデートした時 or OSのサポートが切れて新しく作り直した時、どういう処理を確認できたら新しくxxxサーバを正常に作り直せたか？という正常系の管理がされていないのでサーバアップデートや作り直す新規作成の難易度が高くなっている。
→正常系の管理を行う - SLA、顧客満足アップの為。アプリ系API , 認証系API群の死活、パフォーマンス監視。
現状はCSからの報告で「１週間ぐらい落ちてたかも？…なのでSLA10%減」になっている。早期発見がSLA向上になる。xxxさんによると既存ツールで安価でできる模様なので。 … DATADOG採用ならそちらで
提案例1
QCDで(品質・コスト・納品)で、
Q とCDはトレードオフになりがち。
機能要件を満たすCDのリリース優先でQが管理されてなくてxxx事業部で問題になっている感ある。// ドキュメント残すようになったり、インフラや技術負債のデトックス。サーバチームとして次期から無限にデータが増えることで性能劣化するユーザ向けコンテンツに対する非機能要件に対するタスク見積もりの試みはあるけども。→
具体として、
- PM担当 … プロジェクトをCDでリリースまでする責務
- QA担当 … Q(品質)を担保するQA(品質保証)を責務
PM2人体制から, PMとQAマネージャで分離するか、
QAマネージャ新たに作るかで責務と予算を分けると良いかも説
提案例2
思いつきだけど、
BaseみたいなシンプルなECモジュールつけれたら良いかも？
ブース出展機能・かんたんLIVE配信の価値も高めたい。出店者ブース・かんたんLIVE配信で、
配信しながらそのまま動画マーケしながら販売できるようになるし// 売上に繋がるショッピングカート機能作りたい！「今」ならEC開発経験豊富なN田さんいるし＞＜・商品紹介のランディングページ機能
・かんたんLIVE配信中にポップアップやCM販売 … ライブコマース
・ブース閲覧履歴や視聴履歴の属性から商品レコメンド // 無形商材も販売できるようにする！
売り上げに応じて手数料も取れる… 売上アップ
→
ブース出展・かんたんLIVE配信するのもプロモーションが目的で、
更にEC機能で顧客にベネフィットを説明しやすく、
数字も出せるので、
売りやすくもなる … 契約コンバージョンアップ
→
購入者にメルマガでアップセルも出せる。
ユーザリストの価値もアップ！
顧客に使い続ける理由ができて担当者が使用継続の社内稟議も通しやすく、
長く使ってもらえる … MMRアップ （楽天出身のスペシャリストが社内にいた気がするぞ！？あれ…もしかして？ご検討くださいませ＞＜
…etc
2021年04月07日〜
【自社サービスのイベント支援WEBサービス改修 ver2.0にてバックエンドを担当】
【チーム構成】
企画2名、デザイナー1名、バックエンド4名、フロントエンド3名、アプリエンジニア1名、リーダー1名、PM1名、グロースエンジニア1名、営業・ディレクター12名、事業部長1名、ブリッジエンジニア1名、海外子会社１社
【業務内容】
- OpenID連携モジュールの開発
Authrization code flowに沿ったOpenIDプロバイダに限定した連携モジュールの設計・開発
OpenIDモジュール開発担当は２人で、私は認証サーバ側を担当。
アプリ側サーバ担当と連携して設計・開発を行なった。
- Firebase カスタムトークン認証によるRealtime DBセキュリティルール最適化 技術検証
- コストカットによる80万/月の月額コスト削減
- AWSリソースのキャパシティプランニング・サイジング
【OpenID連携モジュールの開発】
- Authorization_code_flowが適用されているOpenIDプロバイダであれば、アプリにログインを利用できる機能の開発
- SNSだけでなく、もちろん顧客の外部公開していない認証サーバとの連携もOpenID連携モジュールを利用してアカウント発行・ログインできる
- プロフィール情報の紐付け
- 顧客の独自OpenIDプロバイダのパラメータとトークンエンドポイントパラメータのバインド
【Firebase カスタムトークン認証によるRealtime DBセキュリティルール最適化 技術検証】
次期プロジェクトで対応する為にアクセス制御の適切なルール設定の技術検証を行った。
Firebase RealtimeDB Rule + Firebase Authentication カスタムトークン認証 + JWT
【 コストカットによる80万/月の月額コスト削減】
- 必要以上のインスタンスサイズ
- アタッチされていない無駄なディスク
- テスト用の無駄なインスタンス
- 利用していない無駄なサービス
- AWS Compute Optimizerの利用による一覧抽出
MRRに匹敵するコスト削減の提案と実行🔥
「コストカット = 粗利」であることを社内に周知で全社最適化！
【某サーバのUDPでの異常通信と対応】
Zoomで画面共有しながらインシデント対応から今後の対応方針策定まで最速で行いました。
- UDPパケットの異常通信をAWS GuardDuty+Slackにより検知
- 一時停止を行い、複製サーバにて調査を行った。
・不正ログイン調査
・プロセス・ネットワーク調査
・マルウェア調査 - 公開ディレクトリにてWEB Shellによるマルウェアの存在を確認
# ls -lhat total 26M -rw-r--r--. 1 apache apache 1.7K Jun 25 09:27 owh.php -rw-r--r--. 1 apache apache 299 Jun 24 21:28 c.php (略)
今後の対応方針として、
- オフショア開発での開発元に
・クリーンインストールからの再デプロイ
・セキュリティグループなどのアクセス制御
・サーバの更新
・アプリの更新
・通信・ポートの制御
・余分なサービスを止める
・管理を日本への移管
現状のサーバを調整するなどそのまま使わず、クリーンインストールしてから再デプロイの上で、私がレビューする流れを案を策定し、クローズとした。
【脆弱性管理】
チームとして週に一度脆弱性をチェックすることを提案して採用されました。
CVEにて公表されている脆弱性はうさちゃんでもできるぐらい簡単なことを周知して横展開。
他部署で開発系ライブラリのインシデントがあったので。
バージョンアップも大事だけど。開発系ライブラリをデプロイしちゃってる製品の運用が問題であることを周知。
気づきベースで色々周知してます。
【Openworkの口コミを書いた】
https://www.vorkers.com/user_answer.php?vid=a0A2x000006z4ap
2.7だった点数を3.07に上げて上位24%になりました。社長が「採用で困っています。素直に、今いる社員なら悪いことも受け入れるから。書いて欲しい」と朝会で全社員に語りかけましたが、80人いた社員で書いたのは私1人でした。これによって採用しやすくなったと聞いています。
組織にとって泥臭くも着実に課題に対して提案・解決を行います🐱✨
社内LTでの発表🐱⚡️
半期毎に半期での取り組みを会場を貸し切って発表します。// 制限時間2分
// 薔薇をまいて登場(=^x^=)ノ🌹
小さき一社員でも、
会社を変えることができる！行動することで未来を変えることができます
社長が就活サイトの会社のレビューが低く困っている、
みんなに書いて欲しいと聞けば秒で動くことで2.7だった点数を、4万点にしました！
… 少し言い過ぎました(*^_^*)
秒で動けば解決できる課題はみなさんの目の前にあります。
担当技術者の知見によって成果物の精度がばらばらになってしまう問題があります。
それは会社としての管理上も、お客様にも決して良くありません。そこで一社員ながら役員に提言することで、 次期から組織の集合知を活かした「標準」を策定し、
レビューする仕組みが生まれることになりました！様々な活動は小さな点ですが、そのいくつかが芽吹いてきました。
来期より会社が強くなることを確信しています！小さい課題は自分が秒で動くことで解決しましょう。
大きい課題は、「正論なのはわかるけど、すぐには出来ないよね」。自分が動くことでその行動による価値を周囲に共感して貰うことでカルチャーとなり根付かせること。
時に困難もあります！
…
私は原宿の道端の絵の１枚です。
値付けはまだされていません。１人でも感動させ価値を感じて貰えれば、「作品」となります。
多くの人の心動かしたならば、
それは「アート」になります。私はアートになりたい！
ここにいる80人が動いた、ならば！
100万ある課題であっても、
すぐに！なくなりましょう！私を、皆さんの力でアートにしてください！
お願いします！
ノーベル賞でお願いします！
// バラを投げる(=^x^=)ノ🌹
2021年07月07日〜
【自社サービスのイベント支援WEBサービス改修 ver2.1にてバックエンドを担当】
【チーム構成】
企画2名、デザイナー1名、バックエンド4名、フロントエンド3名、アプリエンジニア1名、リーダー1名、PM1名、グロースエンジニア1名、営業・ディレクター12名、事業部長1名、ブリッジエンジニア1名、海外子会社１社
【業務内容】
SRE的業務
Datadog本番リリース
・Datadog Agent用のAnsible作成
セキュリティ, 脆弱性対応
改善課題15個を改善
バックエンド開発業務
- クライアント毎のリードへの一斉メール通知機能
SendGridとの連携。一斉メール送信を実現
・一斉送信
・予約送信
・予約送信リクエストキャンセル
・予約送信リクエスト削除
・CSVアップロードによる一斉送信
・CSVによる除外メールアドレス機能
・既存会員データを利用したCSVの作成
・会員数5万人+5万レコードCSVのによる一斉送信テスト - テンプレート機能の追加
テンプレートからカスタマイズすることで最速でアプリをリリースできる機能です。
プレスリリース
既存のアプリ構成情報を複製してテンプレートとして複製機能クライアント毎のリードへの一斉メール通知機能
ノーコードイベントプラットフォーム「eventos（イベントス）」がSalesforce連携、メール配信機能など大幅な機能アップデートを実現！
https://prtimes.jp/main/html/rd/p/000000076.000054681.html
統計情報の扱いや予約配信機能など、SendGrid特有の仕様に合わせて実装。
簡単やんけ🐱
と思われたが既存のアプリデータと組み合わせるとServiceクラス側がなかなか複雑なものになったが、それでも保守しやすいように関係事にクラスとメソッドを適当に分割し保守しやすいように心がけた。
【開発系EC2, AutoScalingGroup環境を営業時間外に停止させるスクリプト】
API Gateway + Lambda tagを指定してEC2の起動・停止 | AutoScaling Groupのインスタンス数を変更 Python3.9
開発系環境のEC2の9割を営業時間外を停止させることで、大幅コストカット🐱💰
リリース間近で深夜残業したい時は、S3にあるHTMLからAPI GatewayにPOSTすることでdev, stg環境を任意で指定して全台停止・起動できます。
【Datadog】
GitHub ansibleDatadogAgent
Datadog AgentのデプロイにはAnsibleを使っています。
GitHub datadogConsole
Datadogコンソールの設定は極力コードベースで設定します
コード化することで
-
コードとして設定履歴が残る
-
内容理解をすれば、変数を変更するだけで変更や追加、横展開がかんたん！
-
スクショをとって手順書を作るのも良いですが、Datadog側のアップデートで手順書が使えなくなる。
→ APIの値はSaaS側で変更されにくい。ブラウザでの設定変更よりスクリプトでの変更の方が楽です。 -
設定が壊れても、リポジトリにスクリプトがあるので復元できますよ！🐱
社内ISUCON 参加決定🐱
7チームのうちの1チーム。チームリーダに選任されました。
- リーダー … 私
- メンバー … 2名
３位でした😸
AWSのコストカット 今期予算比600万円安達成
初期は40万円だったものが、ランニングコストが膨らみ続けて最大500万円/月まで膨らんできていました。
- AWSの無駄なリソースを断捨離の断行
・リソースの洗い出し
・無駄なバックアップの削除
・利用していないAMI, Snapshotなどの削除
・増え続けるバックアップを発見
・世代間バックアップに変更
・異常な富豪システムの発見
・適切にサイジング - 処理の高速化
→リソースの最適化 - リソースのサイジング
→
・ AWS compute-optimizer
・キャパシティプランニングの実施
・夜間、休日の開発、ステージングサーバの停止自動化
今期で90-120万円/月減らして、
230万円/月あたりまでに減らせた🐱
1-8月予算比で600万円カットを達成💰
●技術選定
・タスク見積もりとスケジューリング
・選定と検証
・インフラ、バックエンドを1人で実装。他レビュワー２名による。
●インフラ, API構築
・Terraform
・tfnotify, Slack, SNS+Chatbotによる通知
・CI/CD, API含めてTerraformによる構築
・AWS Secret Managerによる機密情報の秘匿化と安全利用
・Python3.9
●アーキテクチャ
CloudFront -> API Gateway -> Lambda -> RDS Proxy ->Aurora Cluster
●CI/CD
GitLab -> AWS CodePipeline(CodeCommit -> CodeBuild(Terraform Plan) -> Slack -> 手動承認 -> CodeBuild(Terraform Apply) -> (API Gateway + Lambda)
●APIGateway + LambdaによるAPI作成
・Python3.9
・Lambda Layerによるライブラリ・関数Utils共通化, 共通処理切り出し
・AWS SecretManager
・ORM SQLAlchemy
・API Gateway Lambdaカスタム統合実装でのカスタムエラーレスポンス仕様によるマッピング対応
・OpenAPI3によるAPI Gatewayインテグレーション
・CloudFront -> API Gateway -> Lambda間へのHeader情報のリクエスト渡し
・API Gateway | 統合レスポンスでのLambdaからのカスタムエラーのマッピングテンプレート対応
・JMeterによる負荷試験、チューニング対応(目標値 333rps 25,000アクセス/分)
・API Gatewayのリクエスト、バースト閾値引き上げ。Aurora max_connections閾値引き上げ
・API Gateway, Lambdaのquota引き上げ対応 ConcurrentExecutions 1,000 -> 10,000
・1,500rpsでの安定稼働サイズ、設定値の確認
・既存環境の限界の2,000rpsに達した場合の施策案
・2,000rpsになる場合はLambda性能が高い海外リージョンへの変更
・東京リージョンはアイドル時のConcurrentExecutions値が500。オレゴンでは3,000の為
・Auroraのインスタンスタイプ変更によるスケールアップ
【社内勉強会】
・Terraformハンズオンを開催
https://www.yuulinux.tokyo/21394/
ver3.0
【Google AuthenticatorによるMFA２段階認証機能】
●担当機能
・フロント１名
・バックエンド1名(私)
・バックエンドレビュワー2名
・DB設計
・APIドキュメント作成
・シーケンス作成
・ライブラリ選定
・Laravel
・コーディング
・マイグレーション
・セキュリティ要件定義
・ログイン試行回数制御機能
・トークンのリセット機能
【一斉メール送信機能改修】
・CSVと変数タグによる動的送信機能追加の改修
・負荷テスト