• 🧑‍💻 I'm a Infrastructure engineer.
• 🌱 I’m hobby Basketball, Shogi
• 📫 How to reach me: X - @kyrieee_a

• AWS

  • Amazon Elastic Compute Cloud (EC2)
  • Amazon Relational Database Service (RDS)
  • Amazon Virtual Private Cloud (VPC)
  • Amazon CloudFormation
  • Amazon VPC Endpoint
  • Amazon Simple Storage Service (S3)
  • Amazon Elastic Load Balancing (ELB)
  • Amazon Route 53
  • AWS Certificate Manage (ACM)
  • Amazon CloudFront
  • AWS Network Firewall
  • Amazon Elastic Kubernetes Service (EKS)
  • AWS WAF
  • AWS Site-to-Site VPN
  • Amazon EventBridge
  • Amazon ECR
  • AWS CodeCommit
  • AWS CodeBuild
  • AWS CodePipeline
  • AWS Key Managemente Service

• Container
  • Docker
    • Dockerfile
  • Kubernetes
    • マニフェストファイル

• OS:
  • Windows
  • MacOS
  • Ubuntu
  • Red Had Enterprise Linux9
  • Amazon Linux2023

• DB:

  • Oracle 21c
  • MySQL 8.0.35

• Programming Languages:

  • VBA
  • GAS
  • SQL

• Tools
  • Git
  • GitHub
  • Notion
  • Redmine

• AWS:
  • Amazon Inspector
  • Amazon Systems Manager
    • State Manager
    • Run Command

• Languages:
  • PHP
  • HTML
  • CSS

• Other:
  • Nginx
  • Virtual Box
  • Terraform

基本設計において以下を担当

• 性能設計書作成
  • 性能設計書の作成では性能対策の内容について作成。 具体的にはEC2, EBS, コンテナ, RDSに対してAWSのベストプラクティクスを参考に性能対策項目の洗い出しを実施。
• システム構成図作成
  • システム構成図の作成では各基本設計書から内容を洗い出し、本番環境/検証環境/開発環境各構成図を作成。

詳細設計において以下のAWSリソースのパラメータシートを作成

• ネットワーク設計 (VPC, Subnet, Route table, VPC Endpoint, Route53, Site-to-Site VPN)
• セキュリティ (AWS Network Firewall, AWS WAF)
• 外部接続 (Amazon CloudFront)
• コンテナ (Amazon Elastic Kubernetes Service, コンテナイメージ, マニフェストファイル)
• データベース (Amazon RDS for MySQL)
• Kubernetesマニフェストファイル

構築業務において以下を担当

• CloudFormationテンプレートの作成
  • VPC
  • Internet Gateway
  • Subnet
  • Nat Gateway
  • VPC EndPoint
  • RouteTable
  • Security Group
  • Network ACL
  • Network Firewall
  • CloudWatch Logs
  • S3
  • KMS
  • EKS Cluster
  • ECR
  • EFS

詳細設計において意識した点は、自分があまり触ったことのないサービスについてはドキュメントを調べるだけではちゃんとした説明をする自信がなかったため、ちょうどその時期開催していたQiita Engineer Festaを利用して都度アウトプットするようにしました。 そうすることで、自分の中に知識が定着し、レビュー時には「なぜこういう設計にしたのか?」を根拠を持って説明できるようにしました。 上記をすることでレビュアーに納得してもらえるように意識しました。 結果、内容には納得していただけることが多かったです。

ネットワークに関わるCloudFormationテンプレートを1ヵ月で作り終えてほしい、という要望があり、 3AZ、本番、検証、開発、災対環境を構築するテンプレートを1から作り上げていくことに相当苦労しました。 環境差異がある点についてはConditionsおよび組み込み関数のIf文を使用して条件分岐させるなどして対応することで効率的にコードを記述することを心掛け、膨大な量のリソースを作成する必要があったため、やむを得ず土日も対応し何とかタスクを完了させました。

また、コードを記述する上での細かい規約がなかったため、他の担当者とも書き方の統一をある程度図る必要があったため、簡単ではありますがコードの規約を作成するなど工夫しました。 具体的には - 各環境差異はConditionsを使用して記載する - 論理IDはパラメータシートの値からかけ離れたIDにしない - OutPutsで対象リソースをExportする際には!Subを使用してParameter値を動的にExportし、別yamlでImportできるようにする など基本的なルールを設けることで各担当が困らないように考えました。

ドキュメントのレビュー前チェックにおいて担当者間によるセルフチェックのクロスチェックを実施する方針でしたが、チャット上でやり取りがされているため、今誰が依頼をしていて、誰がクロスチェックしているのか？がPM、PLがすぐに把握できない状況かつ、チャットが流れてしまい放置される状況を解消すべく、Plannerを活用して各担当者のセルフチェック実施状況を可視化できるように提案しました。 結果採用され、うまく可視化される運用となりました。

• Python3.8 -> 3.12のバージョンアップ対応

  • バージョンアップに伴う影響調査: 3.12で廃止されるPythonのクラスや関数などを調査し、調査したクラスや関数が使用されていないか確認
  • バージョンアップ手順書の作成/更新作業の実施: 更新対象のCFnテンプレート修正 -> S3バケットに格納されているCFnテンプレートをCodeCommitにファイルをアップロード -> CFnスタックの更新を実施
  • Amazon EventBridgeのスケジュールに従って実行されるPythonの動作確認

• Amazon Linux2 -> Amazon Linux2023へのバージョンアップ対応

  • バージョンアップに伴う影響調査: Dockerfileに記述しているAmazon Linux2のイメージ情報および必要パッケージの情報をAmazon Linux2023に更新し、コンテナが正常に動作するかの検証(docker buildが問題なく完了するか、docker run後に意図したプロセスが立ち上がっているか)

• CloudFormationテンプレートの構築

  • 基本的にCloudFormationでの管理になっていることから、追加で必要になったリソースについてはCloudFormationを用いて構築。

Amazon Linux2(以下AL2)とAmazon Linux2023(以下AL2023)ではベースOSが異なることから、AL2そのままのDockerfileでbuildがうまくいかない、必要なプロセスが立ち上がらないという状況が何度も続き、解消するために非常に苦労しました。 しかしながら、エラーを遭遇する度に、なぜこのエラーが出るのか？解決方法は何か？を一つ一つ地道に調べて解決していけたことで、非常に理解が深まったことで自信につながりました。

具体的に、AL2はRHEL/CentOSベース、AL2023はFedora34～36ベースとなっているため、FedoraにEPELリポジトリを導入できないことから、lsyncdをパッケージから取得できない問題などが発生し、その点を解決することに苦労しました。 結果的にFedora 36レポジトリ導入を行い、そこからlsyncdの導入をすることで解決した、という経緯があります。(この点はAWSのサポート外となるため、会社判断となりますが…)

• 運用設計書作成 -> 運用手順書作成 -> 運用テスト仕様書作成 (一部) -> 運用テスト
• サブリーダー

主にインシデント管理に関する設計担当として以下を担当

運用設計書 / 運用手順書作成

• オンプレ基盤上のインフラ監視(ログ監視/ジョブ監視/プロセス監視/死活監視/ウイルス監視/不正接続/セキュリティインシデント検知/ファイアウォールログ管理/初動対応 -> インシデント管理システムへ連携するまでの流れ)
• インシデント/障害対応(監視システムによるアラート検知、およびユーザー問い合わせからのインシデント/障害判定 -> その後の影響確認/調査/対応/復旧までの流れ)
• ウイルス対応(ユーザー端末/サーバ/メールなどによるアラート検知およびユーザー問い合わせからのインシデント/障害判定 -> その後の影響確認/調査/対応/復旧までの流れ)

7名規模のサブリーダーを担当しています。 具体的には以下のような内容を従事しています。

• ドキュメント作成における運用ルール化 -> フォーマット作成、記述ルールの統一
• タスク管理ツール導入 -> Plannerにて進捗管理を実施
• メンバー教育 (設計メンバーおよびオペレータへのOJT, 指示出し)

運用手順書を作成する際に、フォーマットがない、記述ルールがない、といった情報のため、この状態からメンバー各々に運用設計書をもとに手順書を作らせようとしても、そもそもどう作れば良いのか、作れたとしてもバラバラのものが出来上がり成果物としてのクオリティに差が生じると感じました。

そこで、まずはフォーマットおよび記述ルールの統一化が必要と思い、そこに着手しました。 フォーマットはコピペができるように準備、記述ルールはPlanner内に細かく記述し迷ったらPlannerを見ることとしました。

上記を実施することで、バラバラの成果物になってしまう課題を解決し、かつメンバー全員が共通認識で作業を進められるように推進しました。

クラウド型電子カルテのクライアントへの導入および社内SEとして従事。 主にクラウド型電子カルテのプラグインツールの導入、運用、障害対応、社内運用業務の自動化などを担当

• クライアント端末へのプラグインツールのセットアップ
• クライアント端末とネットワークセグメントの異なる他社端末へのネットワークルーティング設定(PowerShell, Terminalなど)設定
• ネットワーク疎通確立後のプラグインツールを使用したファイル連携テスト
• 社内運用業務効率化のため、GASを使用した運用自動化を実施
• Notionを導入し、顧客管理ツール化、社内Wiki化などを構築
  • スケジュール管理、進捗管理などの業務の見えるかを実現
• 仮想Linuxを用いたレセプトコンピュータのシステム構築
• 利用した技術スタック
  • 言語: GAS, VBA
  • OS: Ubuntu, Windows10, Mac
  • ミドルウェア:
    • DB: PostgreSQL
  • 各種ツール:
    • Notion

• GASを使用した自動化を行い、年間300時間程の効率化を実現
• Notionを導入し情報の一元管理を実現

今週「誰が」「何をするか」の作業を忘れないで実行する作業を、作業日程表を毎回目視で確認しながら進めるには、工数がかかる、目視確認の漏れが生じる、という課題がありました。 そこでGASとSlackを連携させた自動通知機能によって、工数削減、抜け漏れという課題を解決しました。

spreadsheetで管理している表から対象のクライアント、作業日、担当者をGASで取得し、1日前に対象のSlackチャンネルに通知する仕組みを作成 -> これらを実施することで、作業者の事前準備等が滞りなくできるようになりました。

• AWS認定資格 ソリューションアーキテクトアソシエイトの教科書: 合格へ導く虎の巻 Kindle版

上記の執筆に携わりました。

• 累計ダウンロード数は15,000冊に到達

Amazon Elastic Load Balancing, Auto Scaling, Amazon EventBride, AWS Systems Managerの執筆に携わりました。 見やすいドキュメント作成をすることが可能です。 インプットだけでなく、意識的にアウトプットを日常から実施することで、ドキュメント作成(設計書など)においては特に役立てるかと思います。

• AWSで実践するEC2の脆弱性対応: 脆弱性ってなんですか？でも大丈夫！EC2の脆弱性対応を知識0からEC2脆弱性をハンズオン対応

• CodeシリーズでハッピーなCI/CDを構築しよう【AWSハンズオン虎の巻シリーズ】

Tools Used:

• Notion, GitHub, Googleドキュメント, Googleスライド

Details:

• Notion:
  • Wikiなどを作成しナレッジの共有
  • プロジェクト管理
• GitHub (コマンド):
  • ブランチを切りMarkdown形式で作成
  • プルリクエストでレビュー依頼

具体的に何をやっているか:

• メイン執筆者から依頼のあった部分執筆, 図解作成、改善, 文章構成確認、校正

• 担当したドキュメント:

  • DBeaverを使用したプライベートサブネットに配置したEC2を経由したRDS接続 (執筆)
  • CloudFormationの解説 (執筆)
  • パッチ適用で既知の脆弱性に対策できるが、未知の脆弱性に対策できない (図解)
  • Amazon Inspectorがどういう仕組みで脆弱性をチェックしているか (執筆)
  • Systems ManagerのRun Commandでできること ログをS3へ出力するためには (執筆)
  • Iacツールについて Terraformとは、Terraformの特徴、CloudFormationとの比較 (執筆)

• AWS公式ドキュメントの読み込み、そこから読者に対して解釈しやすい文章作成をしますが、まずAWS公式ドキュメントを熟読 -> 自分なりに解釈した文章にアウトプットをすることで、担当したAWSリソースの深堀りができたことで、知識の定着させることができました。 併せて、ハンズオンの手順を作成するドキュメントもありますので、構築する作業も併せて実現できました。

AzureやGoogleCloudと比較しても、シェア率が一番高いため、情報量も豊富にあり、学習しやすい、ナレッジが多いということからAWSを選択肢とする企業も多く、採用の間口も広いのではと思っているため、AWSを勉強しています。