Business social network with 4M professionals

Open in app
moritakee
moritakee
moritakee

moritakee

パーソルキャリア株式会社 / インフラエンジニア沖縄県
0Connections0Followers
Message
Register to view full profile

moritakee

パーソルキャリア株式会社 / インフラエンジニア

Message
Register to view full profile

Self Introduction

Available to logged-in users only

Log in to continue
About パーソルキャリア株式会社

パーソルキャリア株式会社2 years

インフラエンジニアPresent

- Present

- 自社WebサービスのインフラをAWSからGCPに移行

  • AWS環境のセキュリティ対応

    ## プロジェクトの目的‧背景 AWSインフラのセキュリティ対応を実施しました。 ## プロジェクト規模‧体制 - インフラチーム3名体制のメンバーとして参画し、会社統合に伴い1名体制となった ## 担当業務‧役割 - DBのVPC/サブネット移行 - 各種ログの保存 - WAFの導入 - GuardDuty ECS Runtime Monitoringの導入 - 踏み台サーバのリプレイス - OV証明書への切り替え - ドメイン移管作業 ## 使用技術 - AWS - Terraform ## 具体的な取り組み 親会社から要求されるセキュリティ基準に準拠するために、既存のAWS環境の問題点のリストアップと以下の改善活動を行いました。 - DBのネットワーク移行 - 過去のリプレイスの経緯からDBがアプリケーションと異なるVPCに配置されていたり、サブネットが適切に構築されていなかったため、VPC/サブネットの移行を実施しました。 - WAFの導入 - GuardDuty ECS Runtime Monitoringの導入 - 親会社およびID連携先サービスからのマルウェア対策要求があったため導入しました。 - 踏み台サーバのリプレイス - SSHでの接続となっていたことと、監査ログが取れない構成となっていたため、セッションマネージャーを利用する形式にリプレイスしました。 - OV証明書への切り替え - セキュリティ基準として、DV証明書ではなくOV証明書への移行が必要となったため対応 - ドメイン移管作業 - 会社統合に伴い、不要ドメインの解約やドメイン移管などドメイン周りの対応を実施

    -
  • クラウド移行

    ## プロジェクトの目的・背景 親会社への統合に伴い以下を実施しました。 - AWSからGoogle Cloudへの移行 - インフラコストの最適化 - システムの可用性向上・セキュリティの強化 - 開発者体験(DX)の改善 ## プロジェクト規模・体制 - 自社エンジニア3名と親会社側が10名程度 ## 担当業務・役割 - インフラ移行の主担当として以下を担当 - インフラ設計・移行計画の立案と実行 - CI/CDパイプラインの刷新 - セキュリティ設計 - コスト最適化 ## 使用技術 - Google Cloud(GCLB・Cloud IAP・Cloud CDN・Cloud Storage・Direct VPC Egress・CloudRun) - Terraform・Trivy・tflint・tfaction・tfcmt - GitHub Actions - k6 ## 具体的な取り組み 自社WebアプリケーションをAWSからGoogle Cloudにリプレイスするプロジェクトのインフラ移行を担当しました。また、インフラ移行に合わせて以下の改善を行いました。 1. ネットワーク・セキュリティ強化 - ネットワークの統廃合・適切なサブネット分離 - 社内向けサービスの認証追加やHTTPS化 2. CI/CD改善 - CIをGitHub Actionsに移行し、月間実行時間を約50時間削減・月間コストを75%削減 - CDをデプロイ用chatbotからGitHub Actionsに移行し、デプロイの高速化と安定性を実現(デプロイ時間を15分→7分に短縮) 3. インフラコスト削減施策 - 開発環境のロードバランサーを1つにまとめる - UptimeChecksを使いCloudRunを擬似的に常時稼働させ、コスト最適化とコールドスタートを回避 - 過剰気味だったDB・Cacheのスペックを最適化 4. インフラのモダン化 - 一部EC2で動いているものをコンテナ化してCloudRunに移行 - 社内向けサービスのセキュリティ向上のためCloud IAPによるSSO認証を設定 ## 工夫した点 1. CDの高速化・民主化 既存のCDはAWSのCodeシリーズに密結合になっており、保守性が低い・デプロイ処理が遅いという課題がありました。 [保守性が低い]に対しては、GitHub Actionsというデファクトなサービスへの移行・デプロイの流れを開発メンバーに共有することで基本的に誰でもメンテナンスできるようにしました。 [デプロイ処理が遅い]の改善のために、まずはコンテナイメージのビルド高速化を行いましたが、自社のWebアプリケーションの構成上、コンテナイメージのビルドキャッシュが使えない状況でのライブラリ(gem)のインストール処理に時間がかかるということが判明しました。(2vCPUのVMで20分以上かかる) これを回避するために、以下の手法を使いました。 - Dockerfileを使ったビルドのライブラリインストール処理でcache-mountを使う - ビルドで利用したcache-mountをGitHub Actionsのcacheに保存し使い回す これにより、ライブラリの更新があった場合でもコンテナイメージのビルド処理が2~4分程度で終わるようになりました。 2. デプロイ用chatbotの廃止 これまで検証環境へのデプロイには、Slackに配置したchatbotを利用していました。 しかし、chatbotの不安定さや保守性に課題があったため、クラウド移行を期にchatbotを廃止しCI/CDをすべてGitHub Actionsで行うようにしました。 新しく作成したCDの仕組みでは、誰でも手軽にデプロイできるようにするためGitHubのラベルを利用して開発環境にデプロイするワークフローを構築しました。 結果として、デプロイの安定化を実現することができ、開発メンバーからDXが大幅に向上したとの声をいただけました。 3. CloudRunのコスト削減 開発者ごとに専用のCloudRun環境を簡単に作成できるように設定できるようにTerraformを整備しました。 また、開発メンバー(約10名)ごとのCloudRun環境のコスト削減とDX向上を目指すため、UptimeChecksを使い定期リクエストを送り常にコンテナを起動状態に保つようにしました。 開発環境では約30ほどのCloudRunサービスが常時稼働していますが、コールドスタートを抑えつつ月のコストを$100程度に抑えることができました。 ## 成果 当初予定していたスケジュール通りにクラウド移行を完了させ、以下を達成しました。 - コスト削減 - よりクラウドネイティブな構成を実現し、インフラコストを移行前から約50%以上削減しました。 - パフォーマンス向上 - Googleサーチコンソールのレスポンスタイムを500ms台から300ms台まで改善することができました。 - DX向上 - CI/CDの安定性と高速化を実現し、DXを向上させることができました。 ## 得られた知見・教訓 - チームワークと信頼関係の構築 - 複数組織が関わるプロジェクトを円滑に進めるには、早期のスコープ定義と責任範囲の明確化が重要だと実感した - プロジェクトマネジメントの知見 - 大規模なインフラ移行では、技術面だけでなく関係者間の合意形成(移行スケジュールのフィックスや統合テスト時の協力など)が成功には重要だと実感した

    -

ファクトマーケティング株式会社1 year

開発部(Side)

-

- EC2で構築されたアプリケーションのコンテナ移行 - 監視・運用・保守

  • インフラのモダン化

    ## プロジェクトの目的・背景 - EC2ベースの従来インフラにおける以下の課題解決 - インフラ管理の属人化（IaC未導入） - デプロイ・マイグレーションの属人化 - 可用性 - セキュリティ・コスト最適化の不足 - インフラのモダン化（コンテナ化）要望への対応 ## プロジェクト規模・体制 - 4~5名の副業エンジニアで構成されるチームに専任インフラエンジニアとして途中参画 ## 担当業務・役割 - インフラリプレイスの設計・実装の主担当 - AWSインフラのIaC化 - CI/CDパイプラインの構築 - セキュリティ強化 - コスト最適化 - インフラドキュメントの整備と共有 ## 使用技術 - AWS(CloudFront・WAF・ALB・ECS/Fargate・RDS・SecurityHub・GuardDuty) - GitHub Actions ## 課題 開発当初は専任のインフラエンジニアが居なかったため、バックエンドエンジニアの開発メンバーの方がEC2ベースでインフラを構築されていました。 しかし、以下の点が問題となっておりこれらを改善するためにプロジェクトに参画しました。 - インフラ周りが適切に管理できていない(IaCなどが使われていない) - デプロイ作業の属人化 - 可用性が担保されていないこと - セキュリティやコスト最適化がされていないこと また、プロジェクトオーナーの方から後々のことを考えてコンテナ化などインフラをモダンにしてほしいとの要望もありました。 ## 具体的な取り組み 上記の課題に対して以下の取り組みを行いました。 1. インフラのモダン化 - バックエンドをEC2からECS/Fargateに移行 - フロントエンドをAppRunnerからECS/Fargateに移行 - コンテナスペックやスケーリング設定など - 踏み台サーバのコスト低減 2. 手動作業・属人化の排除 - GitHub Actionsを使ったデプロイフローの整備 - Notionを使いインフラ周りのドキュメント整備 3. セキュリティ対応 - GuardDutyやSecurityHubを設定・対応 ## 工夫した点 1. 技術選定 AWSインフラのリプレイスを行うにあたり、ECS/FargateおよびAppRunnerのどちらを使うか技術検証を行いました。 私自身AppRunnerの利用経験がないこととAppRunnerの本番利用の事例をあまり聞いたことがなかったため、リプレイスにあたり機能要件・非機能要件を満たせるか検証を行いました。 結果として、以下の理由によりAppRunnerは採用せずECS/Fargateを利用することに決めました。 - 一部AppRunnerのリソースがTerraform管理できない - ネットワーク周りのリソースの更新ができない(削除→再作成となる) - デプロイが遅い(内部でB/Gデプロイが行われているため) - オートスケーリングの指標が限られている(リクエスト数のみ) 2. Terraformを使ったIaC化 既存のAWSリソースは全てIaC管理されていなかったため、リプレイスにあたり全てをTerraform管理するようにしました。Terraformに詳しい開発メンバーがいなかったため、なるべく複雑性を下げるためmoduleは使用しないようにしました。また、コード品質の担保とセキュリティ・ガバナンスの観点からTerraformのCI/CDをGitHub Actionsで実装し開発メンバーでも簡単にPRを出せるようにドキュメントを整備しました。 - PR作成時のCI - plan実行して結果をPRにコメント - tflint・trivyの実行 - PRマージ時のCD - apply実行して結果をPRにコメント 3. コスト最適化の実現 コスト削減のため、踏み台コンテナを常時起動するのではなく開発メンバーが必要なタイミングで起動できるような構成を作りました。 工夫した内容としては、 - Slackから踏み台コンテナを起動 - AWS Chatbotを使って踏み台コンテナを起動させることで誰がいつ踏み台を起動したかを記録できるようにしました - 作業終了時に自動でコンテナを落とす - コンテナのエントリーポイントとして、10分おきにコンテナ内にSSMで接続しているユーザ数をチェックし接続ユーザがいなければプロセスが落ちるようにしました ## 得られた知見・教訓 1. DevOpsとDX向上 - IaCとCI/CD整備により、開発者が安全かつ効率的にインフラ操作可能に - ドキュメント整備による知見共有の重要性 2. 技術選定の重要性 - 新技術（AppRunner）の検証による適切な判断 - チーム全体の技術レベルを考慮した実装方針決定 3. コスト最適化とユーザビリティの両立 - Slack連携による使いやすさの実現 - 自動化による運用コスト削減 4. チーム全体の生産性向上 - インフラ操作の民主化 - 属人化の解消 - 自動化による作業効率の向上

    -
About ランサーズ株式会社

ランサーズ株式会社2 years

開発

-

・AWSインフラの構築~運用 ・新規サービスのインフラ構築 ・SRE活動

  • 各種SaaSのコスト最適化と利用促進

    ## プロジェクトの目的・背景 自社で使用しているAWS・CircleCI・Datadogのコスト削減や利用推進を行いました。 - 各種クラウドサービスのコスト増大への対応 - Datadogの活用度向上とコストパフォーマンス改善 - 開発者の効率的なツール活用の促進 ## プロジェクト規模・体制 - インフラSREチームの1メンバーとして対応 ## 担当業務・役割 - AWS運用コストの最適化 - CircleCIのパフォーマンス改善 - Datadogの活用促進・コスト管理 - 開発チームへの技術共有 ## 使用技術 - AWS(ECS/Fargate・NATGW・VPCエンドポイント) - Datadog - CircleCI ## 具体的な取り組み 1. ECS/Fargateのコスト削減 自社では各サービスの実行基盤をEC2からECS Fargateに移行済みでしたが、EC2時代に比較するとコストが高くなってしまうので、コスト削減のためにFargate Spotの導入を行いました。 基本的には、サービスのトラフィックに応じて最低台数はFargateで起動するようにし、オートスケールで起動するコンテナの一部をFargate Spotで起動するように設定しました。 これにより、ECS・Fargateのコストを40%削減することができました。 2. NATGWのコスト削減 Webアプリケーションではサイドカーとしてdatadog-agentを使っていました。 ECSタスクを起動する際に、datadog-agentのコンテナイメージをNATGWを経由してpullするようになっており、ECSタスクの起動回数が増えるごとにNATGWの通信量が増大していました。 これを回避するために、datadog-agentのコンテナイメージをECRプルスルーキャッシュを使いNATGWではなくECRに対してVPCエンドポイントを経由してイメージをpullするように設定しました。 これによりNATGWの通信コストを60%程度削減しました。 3. CircleCIの改善 CircleCIでは以下の問題があり、これを修正することでコスト削減とコンテナビルドの高速化を行いました。 - CIの最適化 - アプリケーションコードに変更があった場合のみテストを実行するように変更し、無駄なCIが走らないようにしました - 使用するVM・コンテナのresource_classの最適化 - CPUを使わないようなジョブはresource_classをsmallにしてコストを抑えるようにしました。また、使用していた一部のCircleCI Orbsはresource_classのパラメータがなかったので、[PR](https://github.com/CircleCI-Public/terraform-orb/pull/69)を出したりしました - コンテナイメージのビルド最適化 - CircleCIのDLCはうまく使われないことがあるのと消費クレジットが大きいので、`--cache-from`と`--cache-to`を使い、キャッシュ用のイメージをECRに置いて使うことでコンテナビルドの高速化とコスト最適化を行いました 4. Datadogの改善 Datadogの課金体系や課金状況を正しく把握しているメンバーがいない状態となっていました。 また、Datadogを導入したもののAPMやログなど開発者に効果的に使用してもらえるように布教活動ができておらず、コストパフォーマンスがあまり良くない状態となっていました。 上記を改善するために、コスト最適化と開発チームに対してのDatadogの利用促進として以下を行いました。 - Datadogの課金体系・課金状況の調査とチームへの共有 - 無駄なコストの削減 - データ取得不要なEC2の棚卸しや取得対象からの除外、Fargate task数やAPM・Log周りのcommited costの最適化を行いました。 - Cloudwatch metrics streamの設定 - 開発チームへAPMの見方・使い方の共有 上記を行うことで全体で月$700ほどのコストを削減することができました。 また、QAや開発チームのメンバーがDatadogを使いこなすための下地を作ることができました。 ## 定量的な成果 - ECS/Fargateコスト：40%削減 - NATGW通信コスト：60%削減 - Datadogコスト：月額$700削減

    -
  • 分析基盤の構築

    ## プロジェクトの目的・背景 BizチームがKPI分析を行うためのデータ分析基盤を約2週間で構築しました。 データ基盤のインフラにはFargateを使い、CircleCIを使ったCI/CD、Terraformを使ったインフラ構成管理を行っています。 既存の別システムの分析基盤がEC2上に構築されていましたが、運用作業や属人化などが発生していたため、本プロジェクトでは全てのアプリケーションをFargate上に構築しました。 ## システム構成 - Fargate上に構築したDigdag/Embulkを実行し、BigQueryにデータをロード - Fargate上に構築したRedashでBigQuery上のデータをクエリ・分析 ## 使用技術 - AWS(Fargate・RDS・ElastiCache) - GCP(BigQuery) - Terraform 1.0.5 - ETL(Digdag/Embulk) - Redash ### 具体的な取り組み 1. 運用自動化 - EC2での手動運用をFargateで自動化 - コンテナ化による運用効率の向上 - 保守性の改善 2. 技術検証 - Redash公式ドキュメントやコミュニティ資料の活用 - コンポーネント構成の最適化 3. セキュリティ強化 - IAMロールの適切な割り当て - S3からのenv file読み込み - SSMパラメータストアの活用 - secret mountの実装 ### 成果 - 運用工数の削減 - セキュリティベストプラクティスの確立 - 社内ノウハウの蓄積

株式会社ハートビーツ2 years

Webエンジニア

-

・Djangoを使った社内向けwebサービスの開発

  • 社内向けドキュメント生成システムの構築

    ## プロジェクトの目的・背景 - お客様向け各種ドキュメントの生成自動化システムの要望 - 頻繁には利用しないため低コストなシステムが求められる ## プロジェクト規模・体制 - エンジニア3名での開発チームでインフラ・CI/CD構築を担当 ## 担当業務・役割 - AWSインフラのTerraform実装 - コンテナ環境の構築 - CI/CDパイプラインの整備 - サーバレスアーキテクチャへの移行設計・実装 - 開発環境の整備 ## 使用技術 - アプリケーション - Golang 1.16 - AWS(ECS/Fargate・Lambda・SNS・SQS・CloudWatch Alarm) - Terraform 0.13.6 - GitLab CI - localstack ## 具体的な取り組み プロダクトの企画・設計・実装を担当しました。 その中でも主にインフラ・CI/CD の構築を行いました。 当初の設計では、ドキュメントの生成ロジックを持つバックエンドを AWS Fargate で動かしていましたが、処理の実行時間や実行頻度を考慮して、プロジェクトの途中で AWS Lambda を使ったサーバレス構成への移行を提案・実装を行い、コスト削減に大きく貢献しました。(ランニングコストがほぼ 0 円になりました) また、サーバレス化を行いキューイングやリトライ処理を AWS のリソースに任せることで、バックエンドのコードをシンプルに保つことができ、保守性の向上に貢献しました。 サーバレスなシステム開発を行ったのはこれが初めてでしたが、AWS の各サービスのドキュメントを読み、動作確認を行い事を通してサービスの理解に務めました。 ## 得られた知見・教訓 - アーキテクチャ選定の重要性 サーバレス構成にすることで低コストなシステムを構築することができたが、その分開発環境などは複雑化してしまったので、コストと保守性のバランスを取ることの重要性を学びました。

    -
  • 社内向け監視ダッシュボードアプリケーションの構築

    社内のサーバ運用チームが業務で使用する監視ダッシュボードの企画〜開発の全工程を担当しました。 ## プロジェクトの目的・背景 - サーバ運用チームの業務効率化 - 監視業務の可視化・効率化 ## プロジェクト規模・体制 - 当初4名→2名体制 - フルスタックエンジニアとして企画から開発まで全工程を担当 ## 担当業務・役割 - プロダクト企画・要件定義 - フロントエンド・バックエンド実装 - インフラ構築・運用 ## 使用技術 - バックエンド - Django 2.2 + django-restframework - OpenAPI - Sentry - フロントエンド - TypeScript 3.75 + React 16.9 - インフラ - AWS (ECS/Fargate, S3, CloudFront, WAF) - Azure App Service - Terraform 0.12.24 - Serverless Framework ## 具体的な取り組み - フロントエンド開発の整備(ESLint・Prettier など)やReact 開発のモダン化 - Terraform での AWS 環境構築 - Serverless Framework の導入 ## 工夫した点 経験のない技術要素が多かったのですが、フロントエンドについてはチームの開発効率向上を目的として、関数コンポーネント・カスタムフック・react-testing-library の導入を行ったり、ESLint ・Prettier の整備を行いました。 これは、別プロジェクトにおいて ESLint や Prettier が適切に設定されておらず、開発効率に影響があった経験から、プロジェクト開始時点で Linter・Formatter を導入することを提案・実施しました。 インフラ面では、主に AWS・Terraform について、書籍や AWS blackbelt 等を利用してキャッチアップを行い、ECS/Fargate を使用したバックエンドと、S3・CloudFront・WAF を使用したフロントエンドをほぼ一人で構築しました。 また、別プロジェクトの Terraform のコードが Module 化されておらず環境ごとにほとんど同じ tf ファイルを作成しており、保守性の低さに苦労した経験があったため、本プロジェクトでは Terraform の Module 化 を行いインフラのコード化の保守性向上に貢献しました。

    -

大卒6 years

大卒

-

Hidden: Education and Experience

View moritakee's

Full Profile

This information is visible only to Wantedly users or the user’s connections

View past posts

View mutual connections

View moritakee's full profile

Log in to view profile

Skills

  • インフラ

    0

  • AWS

    0

Accomplishments / Portfolio

Log in to view profile

Receive Scouts from companies

Try App