ID:71014さん

# プロジェクト概要 ## 目的、背景 公共事業向けのサービスを提供するためのコンテナ基盤を構築。 ## 期間・チーム構成 2023/07〜現在も継続中（私の参画は7月だったが、本プロジェクトは同年4月からスタート） （以下の人数は兼務含む） - インフラ基盤チーム - チームリーダー 兼 他チーム調整 ×1人 - ネットワーク、セキュリティ担当 ×1人 - サーバー構築 ×2人 - クラスタ構築 ×1人 - サーバー内のサービス設定 ×4人 - アプリ開発チーム - 人数未確認 ## 担当した役割 インフラ構築とアプリ開発はチームが分かれており、私はインフラ構築を担当。 私は、クラスタ構築をメインに、サーバ構築と、サービスの設定を行った。 プロジェクト全体としては数十名規模だが、インフラ側は7人で対応。 アプリ側は内部で複数チームに分かれており、各アプリ開発チームの要望に応じてコンテナオーケストレーションのクラスタを構築。 Kubernetes及び、Openshiftで構築を行った。 ## プロジェクトに関連するアクティブな資格・認定 - [CKA: Certified Kubernetes Administrator](https://www.credly.com/badges/552dc95b-a2ce-409d-b982-c8cec0a34459) - [CKAD: Certified Kubernetes Application Developer](https://www.credly.com/badges/285b79ee-7e2f-4e7f-b965-8ecee3f5b75b) - LPIC-3: 304 (Virtualization and High Availability) # 開発・実装内容 --- ## 1. Openshiftクラスタ構築 ### 概要 VMware vSphere環境へ仮想マシンを起動し、Openshift4.13によるクラスタを構築。 クラスタ構築は、私一人で対応させて頂いた。 ### 使用した環境・技術 - VMware vSphere環境へ構築 - Openshift 4.13を利用 - クラスタのノード構成は、master×3、infra×2、worker×2。 - Bearmetalインストール - Openshiftのインストールは環境（オンプレミスやパブリッククラウドなど）によりパターンがいくつかある。 今回はパブリッククラウドではなくVMwareへのインストールであったため、Baremetalインストール方式を採用。 - OSはRedhat推奨の「Red Hat Enterprise Linux CoreOS (RHCOS)」を採用。 - iPXEサーバー構築 - DNS、DHCP、TFTP、WEB（nginx） ### 課題・問題点 - Openshiftクラスタ構築に関する有識者の不在 - baremetalインストールであったため、OSイメージをあらかじめ格納しておくためのPXEサーバーが必要。 - 検証用の環境が存在しなかったため、別途検証環境の準備が必要。 - セキュリティ区画へのインストールであったため、インターネットへ接続するためにProxyサーバーのホワイトリスト登録が必要であったこと。 - サブスクリプションの費用削減のために、infraノードを用いる必要がある。 ### 取り組み - Openshiftクラスタのインストールは初見であったこと、また有識者が不在であったため、公式ドキュメントや書籍、WEB上で検索をし、手順を把握した。 - 検証用の環境が用意されていなかったが、かといって本番環境で検証することは憚られたため、ローカルのPCへVirtualBoxをインストールし、検証を試みた。 しかし、Openshiftクラスタを構成するノードの必要最小スペックが大きかったことから、Openshiftクラスタを構成するためのノードの台数を起動するには、VirtualBoxがインストールされているホストOSのスペックが不足していたた。そのため、VirtualBoxではなく、KVMを検証環境として利用した。 - Bearmetalインストールを行うためにはiPXEサーバー構築が必要だったため、公式ドキュメントや書籍を参考にしつつ準備をした。 - Openshiftは、Redhatが指定している特定のPodをinfraノードで起動することでサブスクリプションコスト削減の恩恵が受けられる。そのため、一部のPodをinfraノードで起動するように設定。 ### 工夫した点 - プロジェクトの現場から貸与されているPCはWindowsマシンであったが、Openshiftクラスタの構築を検証するにはVirtualBoxではスペック不足であった。そのため、個人的に所有しているPCにubuntuをインストールし、KVM環境にてOpenshiftクラスタのインストールを検証した。 検証結果を元に、インストールの手順書を作成。 ### 発生した問題と、それに対する対応 - OpenshiftのBeremetalインストールを省力化することを目的にiPXEサーバー構築した。 DHCPでIPアドレスを割り当て、TFTPで設定を取得し、WEB（nginx）に保存しているRHCOSのOSを取得してくれれば、そのまま全ノードへOSがインストールされるはずであった。 しかし、DHCPによるIPアドレスの割り当てができない事象が発生。 パケットを確認したところ、クライアントからのDHCP DiscoverをDHCPサーバーが受け、DHCPサーバーがOfferを出しているところまでは確認できた。しかし、そのOfferがクライアントまで届いていなかったことが判明。 事象が判明したものの、原因が不明。解決することができなかった。 Openshiftクラスタ構築の期限が迫っていたため、DHCPによるIPアドレスの割り当ては諦め、全ノードに一台ずつログインをし、コンソールからインストールのコマンドを実行。DHCPとTFTPは利用せずにWEB（nginx）に格納したOSをダウンロードするインストール手順に切り替えた。 後日、当該のVMware vSphere環境を管理している部署へ問い合わせたところ、DHCPのパケットはドロップしているとの回答あり。原因は判明したため、本事象はクローズとした。 - OpenshiftのWEBコンソールからログを確認したところ、タイムサーバーに関するエラーが出力。 Openshiftの公式ドキュメントを確認したところ、chronyのインストールが必要とのことが判明。ドキュメント通りにMachineConfigオブジェクトにて対応。手順として見落としやすいと思われるため、チーム内にナレッジとして残した。 --- ## 2. Kubernetesクラスタ構築 ### 概要 VMware vSphereのVMと物理サーバーへ、Kubernetes 1.28によるクラスタを構築。 クラスタ構築は、私一人で対応させて頂いた。 ### 使用した環境・技術 - VMware vSphere環境と物理サーバーのハイブリッド環境へ構築 - Kubernetes 1.28を利用 - クラスタのノード構成は、master×1、worker×5。 - masterのOSはRHELを、workerのOSはubuntuを利用。 - masterはVM環境へ、workerは物理サーバーへのインストールを実施。 - kubeadmによるインストールを実施 - コンテナランタイムは、Containerd、KataContainersを利用。 - CNIプラグインは、calicoを利用。 ### 課題・問題点 - 私自身はKubernetes認定（CKA、CKAD）の取得過程で、VirtualBoxやEKSへのKubernetesクラスタのインストール自体は経験済みではあったが、本番環境へのインストールに向け、あらためてインストール手順を再確認をすることと、プロジェクト内のタスクとして手順書を作成することを目的に、VirtualBoxにてKubernetesクラスタを構築。 その際、VirtualBoxを利用し、OSはCentOSを用いた。 - 本番環境の各ノードは、管理セグメントと業務セグメントの2つにインターフェースを持っていたため、Kubernetesクラスタの構築に当たっては、その点を考慮する必要があった。 - 構築初期段階においては、費用の兼ね合いから、masterノードは1台のみの構築となった。しかし将来的な拡張性を考慮し、クラスタをインストールをする方針とした。 ### 取り組み - Kubernetesクラスタのインストールについては、公式ドキュメントをなぞっていけば、基本的なインストールは難しくはない。 しかし、アプリ開発のチームから、構成に関する要望もあったため、それらを取り込む必要あり。要件を摺り合わせて対応。 - データセンター内にて物理サーバーのラックマウント、ケーブリング、及び疎通確認試験を実施。 ### 工夫した点 - 「kubectl top」コマンドに必要なmetrics-serverは、追加でインストールした。CPUやMemoryの利用状況を確認する頻度は少なからず発生するため。 - CNIプラグインはcalicoを選択した。要件として明示はされていなかったが、Network Policyを設定できるようにしておいた方が良いと判断したため。 - Kubernetesクラスタを構築する際のコマンド「kubeadm init」において、「--control-plane-endpoint」のオプションを用い、そこへKubernetes APIに向けたDNS名を設定した。 そうすることで、構築初期段階においてはmasterノードは1台構成であるが、将来的に3台にする場合に対応できるようにした。 DNSで名前解決をしているIPアドレスは現時点ではmasterノードのインターフェースを指定しているが、masterノードを増やす場合に当たっては、このIPアドレスをロードバランサにて払い出す計画。 ### 発生した問題と、それに対する対応 - pod間の通信において、想定した速度が出ない事象が発生。 ネットワークを担当しているメンバーと共に調査をしたところ、回線の細い管理セグメントを用いて通信を行っていた。（想定では業務セグメントを通るはずだった） calicoの公式ドキュメントで調べたところ、calicoが使用するネットワークを指定する設定が存在することが判明。 calicoが使用するネットワークをKubernetesのInternal IPを利用するように設定して反映したところ、想定通り業務セグメントにて通信するようになった。 今回の問題点としては、Kubernetesクラスタを構築する際にkubeletが利用する回線は業務セグメントのみと設定することで、Kubernetesの各ノードのInternal IPも想定通りとなっていた。そのためcalicoも業務セグメントで通信を行ってくれると思い込んでいたことが反省点である。 今後クラスタを構築するに当たっては、ネットワークが正しく動作しているかと行った観点でも試験をすることとする。 - 物理サーバーのケーブル接続後の疎通試験において、一部の回線でケーブルランプが異常を示していた。インターフェースの情報を確認したところ、回線速度が設定した値になっていなかった。ケーブルの抜き差しや設定の見直しで対応したものの、事象は回復せず。 接続先の対向器機であるデータセンター側資産のL3SWで回線の挿抜を実施して貰ったところ、復旧した。 ここ数年はクラウドに馴染んでしまっており物理サーバーの構築は久々であったこともあり、切り分けの感覚が鈍っていたように思う。 --- ## 3. バックアップ用の運用スクリプト作成とジョブ設計 ### 概要 - VMの定期的なバックアップを実施（クラスタ以外のVM） - コストの兼ね合いからバックアップソリューションは用いず、シェルスクリプトで実現。 - KubernetesのETCDを定期的にスナップショットを取得 - ジョブが失敗した場合のAlert設定 ### 使用した環境・技術 - VMware Cloud Director API v37.1 - etcdctl - Bash - hinemos ### 課題・問題点 - VMの操作を行うための「VMware Cloud Director API」は初見であったため、公式ドキュメントで機能を把握しつつ、検証をする必要あり。 - ジョブを管理するhinemosは初見であったため、公式ドキュメントを確認し、検証をする必要あり。 ### 取り組み - ジョブ管理を行うhinemosの機能把握。その上で、hinemosの機能を享受しやすいような運用スクリプトを作成。 - VMのバックアップは、「VMware Cloud Director API v37.1」を用いてシェルスクリプトにて実装。 - etcdのバックアップはetcdctlを用い、スナップショットを取得。そのファイルをクラスタから別サーバにSCPで転送し保存する、という一連の機能をシェルスクリプトにて実装。 - 作成したシェルスクリプトは、全てhinemosからジョブとして実行するように設定。 ### 工夫した点 - シェルスクリプトは、hinemosのジョブで動作をする前提で機能を分割して作成。 例えば、作成した全ての関数をひとつのシェルスクリプトから順に実行することでも動作自体はするが、関数をジョブ単位で分けてシリアルで実行させることで、エラー時の切り分けや、再実行が容易になる。 また、エラー時の自動再実行や、再実行の回数などもジョブで定義が出来るので、柔軟な対応が取りやすい。 - シェルスクリプトの関数に渡す引数は、hinemosのジョブ変数を受け取り、動作するようにした。 そうすることで、ジョブを内包するジョブネット単位で複製をした際、渡す引数を変えるだけで異なるVMのバックアップを実行することができる。 ### 発生した問題と、それに対する対応 - VMをvSphere内のバックアップ用vAppへコピーをすることで「バックアップ」とする、という方針はチーム内でまとまったものの、「VMware Cloud Director API」の公式ドキュメントからは、それっぽいAPIはあるものの、決め手に欠けていた。 そのため、vSphereのコンソールから手動でVMのコピーを行い、その際にChromeのデベロッパーツールからどのようなAPIでPOSTされているかを読み解き、そこから逆算してAPIが「recomposeVapp」であることを特定。シェルスクリプトにフィールドバックすることで、目的の機能を実現できた。 --- ## 4. モニタリング ### 概要 - PrometheusとGrafanaを用いた監視の設定 - 他のメンバーと共同で設定作業を進めた ### 使用した環境・技術 - Prometheus - Alertmanager - Grafana - Node Exporter ### 課題・問題点 - 全ノードへNode Exporterをインストールし、PrometheusとAlertmanager、Grafanaは監視用サーバーへインストール。 Prometheusで取得したメトリクスを、Grafanaでグラフとして表示させるように設定する。 ### 取り組み - Node ExporterはPodとしてでもインストール可能であったが、プロジェクトマネージャーの意向により、全ノードに対してパッケージでのインストールを行った。 - PrometheusとGrafanaも、監視用サーバーへパッケージとしてインストールをした。 ### 工夫した点 - NodeExporterは実行時の引数が多かったため、Systemcltによるサービスの実行に当たっては、引数を外部のファイルに持たせることとした。 外部のファイルに持たせることで、引数を変更する場合でも、ユニットファイルに影響を及ぼス事が無くなる。 ### 発生した問題と、それに対する対応 - 各パッケージはインストール自体は容易だったものの、Grafanaの設定で躓いた。 一見するとグラフィカルで見やすいが、初見だと設定方法が直感的に分からず、他のメンバーと調査をしながら対応した。 --- ## 5. Tekton/ArgoCD ### 概要 Openshiftクラスタへ、TektonとArgoCDをインストール。 ### 使用した環境・技術 - Tekton - ArgoCD - Operator ### 課題・問題点 - アプリ開発チームの要望により、TektonとArgoCDをOpenshiftクラスタ内に準備。 ### 取り組み - Operatorを用いてインストールができるため、各種Podの起動自体は容易。 - 簡単な動作確認をし、後続の作業はアプリ開発チームへ引き渡した。個人的には、もう少し深いところまで関わりたかったという思いはある。 --- ## 6. DNSサーバー構築 ### 概要 - Openshiftクラスタと、Kubernetesクラスタの名前解決を目的としたDNSサーバーを構築。 ミドルウェアはBINDを利用。 ### 使用した環境・技術 - BIND ### 課題・問題点 - Openshiftクラスタ向けには、Openshiftの公式ドキュメントを参照しzoneファイルを定義。 - KubernetesクラスタのAPI向けには、現時点ではmasterノードを宛先としてzoneファイルを定義。 ### 取り組み - Openshiftクラスタ向けには、直接ノードのIPアドレスを指定するのでは無く、環境内に存在するA10のロードバランサ経由でアクセスするようにした。 なお、A10の操作は、ネットワークを管轄しているチーム内の別メンバーにて対応。 - BINDは、named.confへACLを設定することで、管理外からのクエリを受け付けないように定義。 また、クラスタ外の問合せは、負荷軽減も考慮し、環境内にある別のDNSサーバーへForwardするように定義をした。 ### 発生した問題と、それに対する対応 - 各ノードが、管理セグメントと業務セグメントへ足を持っていること、またファイアーウォールが環境内に存在することから、想定通りの通信が出来ない事象が頻発した。 そのため、ネットワークを管理してるチーム内のメンバーと協力し、対応をした。 --- ## 7. Kubernetesクラスタ構築とAnsibleによる自動化 ### 概要 追加のKubernetesクラスタ構築依頼に対する対応 全サーバーをVMで構築 一部の工程をAnsibleによる自動化 ### 使用した環境・技術 - Kubernetes - VMware vSphere - Ansible ### 課題・問題点 - クラスタの構築の手順は確立されていたが、サーバーの台数が多く手間が掛かる。 - オンプレミスへのKubernetesクラスタの構築は、工程が多く面倒。手作業だとミスを誘発しやすい。 ### 取り組み - Ansibleによる自動化を進める ### 工夫した点 - 新しい事を取り入れようとすると拒否反応がでやすい雰囲気がある。 なので、AnsibleのPlaybookはシンプルに1つで完結させ、手順書を作ることとあまり大差ないことを伝えながら、徐々に浸透させる。

# プロジェクト概要 ## 目的、背景 官公庁が公開しているデータを取得し、住所をGoogle Map上へプロットする ## 期間・チーム構成 2023/10〜2023/12 - チームリーダー ×1人 - インフラ兼バックエンド ×1人 - フロントエンド兼バックエンド ×1人 ## 担当した役割 Dockerを用いたインフラ構築と、Goによるバックエンド開発を担当。 # 開発・実装内容 --- ## 1. WEBサービスの開発 ### 概要 - Djangoを中心としたコンテナの構築 - WEB上から取得したjsonファイルをデータベースへ保存する ### 使用した環境・技術 - Docker-Compose - DB - MongoDB - MySQL - フレームワーク - Djangoo - IDE - JetBrains(GoLand，PyCharm) - API - Google Map API - Golang MongoDB Driver ### 課題・問題点 - 取得したjsonファイルをどのようにインポートするか - インフラ部分をどのように構築するか ### 取り組み - Docker-Composeを使用したインフラ構築 - コンテナ:Django、MySQL、MongoDB - 基盤はレンタルサーバーのVPS利用 - アプリケーション開発（Go） - jsonからMondDBへのインポート - MongoDBコレクション用のCRUD関数作成 - Google Map APIの利用 - 住所をジオコード（地理情報）に変換しMongoDBをアップデート - Django環境構築 - MySQLとの接続と動作試験のみ対応 - 公式ドキュメントのDjangoチュートリアルを元に動作を検証 （DjangoのModelの作成、デザインは他のメンバーにて対応） ### 工夫した点 - インターネットから取得する情報がjson形式であったため、一次格納先としてMongoDBを利用。 Golang MongoDB Driverを利用しやすいようにラッパーし、MongoDBコレクション用のCRUD関数作成。 - 顧客がミニマムから開始したいとのことで、レンタルサーバーを利用。 （固定費のため、コストを見積もりやすい） - 将来的にAWSへ移行することも想定 - Docker-Composeを用いることで、コンテナ群の起動を容易に。 ### 言語やフレームワークの選定理由 - Djangoの選定理由は、メンバーの得意分野であったこと - Goの選定理由は、私自身が個人的にGoの学習をしており、実践で使いたかったため。 このプロジェクトではKubernetesは利用しなかったが、Kubernetesの理解を深めるためにはGoの知見が必須であるため、今後も学習を重ねていきたい。 --- ### *参考資料* *納品した資材を更改することは出来ませんが、構築及びコーディングをする過程において、部品単位で検証した際のリポジトリを参考までにご提示致します。* - *djangoとMySQLのコンテナ* - https://github.com/ken344/container-django - *MongoDBのコンテナ* - https://github.com/ken344/container-mongodb - *mongo-driverのラッパー* - https://github.com/ken344/mongoctl-go/tree/main/connectmongo - *GEOコーディング* - https://github.com/ken344/get-geocode-go

# プロジェクト概要 ## 目的、背景 - 他社が現場から引き上げるため、他社が行っていた運用業務引継ぎ - 障害対応やリリース管理、アカウント（IAM）管理などを対応 - 定常作業として、AWS請求ダッシュボードから費用のグラフ作成など ## 期間・チーム構成 2022/10〜2023/06 - チームリーダー ×1人 - 運用保守担当 ×3人 （チームが所属するグループ全体では、10人程度で構成） ## 担当した役割 運用担当として参画 維持運用、リリース管理、トラブルシューティングを対応 ## プロジェクトに関連するアクティブな資格・認定 - [AWS Certified Solutions Architect – Professional](https://www.credly.com/badges/efce9dd0-6ce1-4972-ac39-ae546497b554) - [AWS Certified Developer – Associate](https://www.credly.com/badges/4ad67e92-14bd-4db1-91cb-64eee9b21fbe) ## 使用技術や開発環境等 - コミュニケーションツール - Teams: チーム内の連携や打合せ - Backlog（nulab）: アプリ開発担当部署との連携、課題管理、故障管理 - Redminie: 他部署や営業間での課題管理 - AWS環境（EKS、EMRを利用したシステム） - IAM - AWSセキュリティポリシー - AWS請求ダッシュボード - 他 # 取り組んだ課題・タスク内容 --- ## 1. リリース管理 ### 概要 - アプリ開発チームからのリリース作業管理 - リリース作業内容を把握しリスクを影響範囲、切り戻し手段などを確認した上で、グループリーダーへの承認フローを回す。 - リリース作業にミスがあった場合の、原因究明や再発防止などを管理する。 ### 課題・問題点 - アプリ開発チームからのリリース作業のエントリー期限は決まっているものの、期限を過ぎてからのエントリーも少なくない。 また、グループリーダーの繁忙時期は、承認作業が滞り、リリース作業日を超過することも散見されていた。 - アプリ開発チームの作業やタスクはBacklogにて管理をしていたが、Backlogの使用の都合上、担当者が1人しか設定が出来ず。そのため、リリース作業やタスクが個人に紐付いてしまい、当人が不在時に対応が滞ることがしばしば発生していた。 ### 取り組み - アプリ開発チームへ、リリース作業エントリーの期限を守るよう、働きかける。 - 作業承認者（グループリーダー）へ、少しでも早い段階から目に付くように申請フローへ乗せる。 ### 工夫した点 - エントリーされていないものの、リリース作業の発生が想定できる案件に関しては、こちらから能動的にエントリーをして貰うよう促す。 - 他社から運用引継ぎを受けた時点では、アプリ開発チームからエントリーされた内容に疑問や問題があれば申請フローに乗せてはいけないというルールだった。 しかしその運用だと作業承認者の目に触れるのがリリース直前になったりするケースもあった。そのため、エントリー内容に問題があった場合でも申請フローには乗せてしまい、問題がある旨を明記した上で、作業承認者へ早い段階から目に触れる状態になるよう、運用を変更した。 結果としては、作業承認者の視点で見た場合のエントリーの問題点も早い段階から拾うことが出来、エントリーから承認までのフローが比較的スムーズになった。 - エントリーされた作業内容を細かく確認し、言語化できるレベルまで理解できるように努めた。 特に、Kubernetesに関してはこの時期は知見がほぼ無かったが、yamlの内容を調べ、理解し、作業承認者へフィードバックできるようにした。 - ひとつの案件（チケット）は一人の担当社が基本的には最後まで対応する事になっていたが、休暇などで不在の際に見過ごすケースが多かったため、運用フローを変えて、日次でメンバーが集まり、進行中のチケットを確認することとした。それにより、チケットが放置されるケースは減った。 - リリース管理や故障対応、運用面の知識や経験は過去の案件でも積んできているため、この案件に関しては過去の知見が活きたと考えている。 --- ## 2. 故障対応 ### 概要 - 日々発生する障害への対応。 役割としては、手を動かすのでは無く、運用部門との故障状況の把握と管理や、影響範囲の確認を行う。 - 障害内容がバグ起因など、修正が必要な場合は、バグが改修されクローズするまでタスク管理をする。 ### 課題・問題点 - 所属チームの温度感と、運用部門の温度感、及びサービスを顧客へ売っている営業部門との温度感が異なることがしばしばあり、故障対応へのスピード感に齟齬が出ることがあった。 ### 取り組み - グループ内の方針や温度感を把握した上で、運用部門へ早期の解決を促し、改修へのスケジュールを整理するといった取り組みをしていた。 ### 工夫した点 - データを販売するサービスを提供している部門であったため、過去のデータに誤りがあることが判明した障害のケースの場合、そのデータを利用している企業の系絵にダイレクトに影響がでる。 そういったケースは、グループリーダーを巻き込み、緊急作業のリリース承認などを貰いつつ、アプリ開発チームへ即時の解決を促した。

# プロジェクト概要 ## 目的、背景 - ETLツール(AbInitio)を用いた、メインフレームからAWSへの移行プロジェクト - メインフレームを担当するチームからSnowflakeへデータが格納される。そのデータを、AbInitioを用いてデータの加工を行い、Amazon S3へ格納する。 ## 期間・チーム構成 2022/05〜2022/09 チームのメンバーは5人。全員がETL（Ansible）の開発、テストを担当。 全体としては40人程度の規模。複数の会社による混成チーム。 メインフレーム側の担当者、AWS側で開発をする担当者などで構成されており、人数は多い。 ## 担当した役割 バックエンド（ETL）、ジョブ設計担当として参画 ## プロジェクトに関連するアクティブな資格・認定 - [AWS Certified Solutions Architect – Professional](https://www.credly.com/badges/efce9dd0-6ce1-4972-ac39-ae546497b554) - [AWS Certified Developer – Associate](https://www.credly.com/badges/4ad67e92-14bd-4db1-91cb-64eee9b21fbe) - LPIC-3: 304 (Virtualization and High Availability) # 開発・実装内容 --- ## 1. ETLツール「AbInitio」を用いたデータトランスフォーム ### 概要 - メインフレームからAWSへデータを移行するためのETLツール（AbInitio）を用いた開発 - ETLツール（AbInitio）を実行するためのシェルスクリプト作成、及びジョブ設計 ### 使用した環境・技術 - AbInitio - Snowflake - Amazon S3 - Amazon linux - JP1 - Bash - Redmine ### 課題・問題点 - SnowflakeからAbInitioを使ってデータを取り込み、ER図を参考にAbInitio内においてDMLでデータを加工。 その上で、Amazon S3へデータを保存するための開発を行う。 - 作成したAbInitioの「Graph」及び「Plan」のテストケースの作成と、テストの実施。 （AbInitioにおける「Graph」とは他言語で言うところの関数に相当し、「Plan」は「Graph」の実行ルールを定めたもの） - 作成したAbInitioの「Graph」をシェルスクリプトから実行し、シェルスクリプトはJP1からジョブとして実行させるように作る。 ### 取り組み - AbInitioはローコードを謳った製品であるが、コードを書く量を少なくさせる分、オブジェクトを操作するためのメニューやプロパティが多く、学習コストが高い。 且つ、ニッチな製品であることから、書籍も無く、WEBで事例を見つけるとも困難。公式ドキュメントと、ベンダーへの問合せのみで、「Graph」を作り込んでいくこととなる。 - AbInitioの「Graph」を実行させ、出力結果により処理を分岐をさせるための「Plan」を作成。 「Plan」はksh（シェルスクリプト）を書いて、AbInitioの出力結果に応じたハンドリングを行う。 「Plan」の開発に関しては、このプロジェクトに着任した時点ではだいぶ慣れてきたこともあり、他メンバーへのアドバイスやレクチャをしながら進めた。 - 作成したAbInitioの「Plan」を実行するため、Bash（シェルスクリプト）とJP1で、ジョブ設計を行う。 JP1に関しても、このプロジェクト着任した時点で、多少なりとも経験値があったため、難易度はそれほど高くは無かった。 なお、AbInitioの「Plan」を実行するBashは、Amazon linuxにて開発し、シェルスクリプトの実行をしている。 ### 工夫した点 - Snowflakeには専用のダッシュボードがあり、そこからSQLを実行できた。そのSQLを参考にAbInitioの「Graph」を作成していく。という流れなのだが、Snowflakeが動作していたOS（Amazon linux）のスペックが低かったこともあり、出力するレコード数が増えるとエラーとなるため、TeraTarmからSnowSQLを実行することで対応した。 SnowSQLの使用方法は、公式ドキュメントを参照した。 - 私自身が、当プロジェクトからの離任が決まっていたため、AbInitioの「Plan」作成におけるコツや、JP1によるジョブ設計や設定の要点をドキュメントに残し、他メンバーへレクチャを行った。

# プロジェクト概要 ## 目的、背景 - Amazon Kinesis Data Streamsからのインプットを、AbInitio（ETLツール）でデータの加工をしS3へ保存、そのデータを利用してAI（Docker Container）が解析し、Tableauで表示をするというシステムの構築 ## 期間・チーム構成 2020/09〜2021/04 チームのメンバーは5人だが、上位会社のメンバーをふくめて10人程度の構成。 （以下の人数は兼務含む） - チームリーダー ×1人 - Tableau ×2人 - データサイエンティスト ×1人 - AbInitio（ETL）開発 ×3人 - ジョブ設計 ×1人 - 監視系 ×1人 ## 担当した役割 私はAbInitio（ETLツール）を使ったバックエンドの開発と、シェルスクリプト、ジョブ設計を主に担当。 加えて、Amazon SNSとCloudWatchを使った監視周りなども担当。 ## プロジェクトに関連するアクティブな資格・認定 - [AWS Certified Solutions Architect – Professional](https://www.credly.com/badges/efce9dd0-6ce1-4972-ac39-ae546497b554) - [AWS Certified Developer – Associate](https://www.credly.com/badges/4ad67e92-14bd-4db1-91cb-64eee9b21fbe) - LPIC-3: 304 (Virtualization and High Availability) # 開発・実装内容 --- ## 1. 監視と通知の設定（Amazon SNS, Amazon CloudWatch） ### 概要 - 開発中のインフラ内で故障が発生した際の通知を行うための設定 ### 使用した環境・技術 - Amazon SNS - Amazon CloudWatch - AWS CLI - Amazon Linux ### 課題・問題点 - AbInitio（ETLツール）を中心に据えて、Kinesis、S3、ECS、AbInitioがインストールされているLinuxにて環境が構成されており、そこでアラートが発生した場合に通知がされる設定を実施。 --- ## 2. AbInitio（ETLツール）を用いたデータトランスフォームの開発 ### 概要 - Amazon Kinesis Data Streamsからインプットされたデータを、Amazon Linux内にインストールされているAbInitio（ETLツール）で処理をし、S3へアウトプット。S3のデータは、ECSへコンテナとしてデプロイされたAIで処理。処理結果をユーザはTableauで閲覧をする。……というシステムにおいて、私はAbInitioの処理の制御を行う「Plan」を開発。 ### 使用した環境・技術 - AbInitio - Amazon S3 - Amazon Kinesis Data Streams - AWS CLI - Amazon Linux - Shellscript（bash、ksh） - PowerShell - VBA（Excel） - vim ### 課題・問題点 - ETLツールであるAbInitioによる開発であったが、一番の課題は「AbInitioが難しい」。 プロジェクトにアサインされた全てのメンバーが、AbInitioがほぼ未経験。 ネットや書籍と行った情報も無く、公式ドキュメントも使いにくかったため、開発が難航した。 AbInitioには大まかな機能として、「Graph」と「Plan」がある。 「Graph」は実行する機能そのものを表し、プログラミング言語で言うところの関数に相当する。 「Plan」は、「Graph」を実行する順序を定めたり、実行結果による分岐を行うことができる。 私は主に、「Plan」の開発を担当した。 - テスト用データの作成と、それをKinesisへ取り込むためのスクリプト作成。 - テストケースの作成と、テストの実施。 ### 取り組み - チーム内のメンバーが作成するAbInitioの「Graph」を実行するための「Plan」を作成。 - 「Plan」内で定義された各コンポーネントは、Linux上ではプロセスとして実行される。その実行結果を受けた処理を、ksh（シェルスクリプト）で開発。 kshを選択したのは、AbInitio内で開発をする際、Bashで作成したファイルをシェルスクリプトとして認識しなかったため。AbInitio内はkshが標準利用。 - AbInitioで開発したアプリの試験としてKinesisへデータをインポートする必要があったため、テスト用データの作成と、インポート用のスクリプトをPowerShellで作成。（pythonで作成する予定だったが、使用環境にboto3が無かったため、PowerShellに変更） ### 工夫した点 - 開発が進んでくると、各メンバーもAbInitioについての知見が蓄積されてくるため、不定期ではあったが、勉強会の場を設けてナレッジをシェアするといった活動をした。 - AbInitioはローコードを謳った製品であったが、実際にはスクリプト作成が必要であり、また設定するパラメータの数が多い。 そのためメンテナンスも大変になるので、「Plan」の作成に当たっては、シェルスクリプトから実行する際に変数を指定できるようにすることで柔軟性を与え、AbInitioの「Graph」や「Plan」の作成数は可能な限り抑えるように工夫をした。 - AbInitioの「Plan」を実行する際に引数として渡す環境定義ファイルは数が多くなったため、Excelで管理をし、VBAで環境定義ファイルをアウトプットするようにした。 --- ## 3. JP1を用いたジョブ設計と、Cronによるログローテーション ### 概要 - AbInitioで開発したアプリを実行するジョブを設計 - 肥大化するAbInitioのログをローテーションさせる ### 使用した環境・技術 - JP1 - AWS CLI - Amazon Linux - Cron - vim ### 課題・問題点 - JP1からAbInitioを実行するためのジョブを設計。 - AbInitioによって蓄積されるログは、放置すると肥大化するのでローテーションをする。 ### 取り組み - AbInitioを実行するためシェルスクリプトをBashで作成。 及び、JP1からシェルスクリプトを実行するためのジョブ作成。 - AbInitioによって蓄積されるログのローテーションを行うシェルスクリプトを作成し、Cronで定期的に実行する。 ### 発生した問題と、それに対する対応 - 実行後の戻りが遅いジョブ（AbInitioのアプリ）を複数同時に動かすと、JP1で設定されている許容される多重度の上限に抵触し、想定通りに動かない事象が発生した。 戻りが遅いジョブはバックグラウンドで動かし、実行後の成否は別のジョブで確認する仕様とした。

# プロジェクト概要 ## 目的、背景 - 金融機関向けのサービスを提供しているSIreでのプロジェクトである - 金融機関向けサービス用のネットワーク新規構築及び、既存回線の更改 - 他事業部からの依頼ベースで発生する ## 期間・チーム構成 2019/10〜2020/08 6人チーム ## 担当した役割 ネットワークエンジニアとして参画 # 開発・タスク内容 --- ## 1. VPNや専用線回線の敷設 ### 概要 - 金融機関向けのサービスが他事業部にて開発された際などに、インターネット向けに回線を敷設する。 VPNをメインに、バックアップとして専用線を敷くと行った構成などが多い。 ### 使用した環境・技術 - ASR1001-X - C3850 - Trinzic825 ### 課題・問題点 - ドキュメント類の準備（設計図、構成図など） - キャリア（ベンダー）のコントロール - 依頼者側とのスケジュール調整とタスク管理 - ネットワーク機器のコンフィグレーション - ベンダー設定機器の受け入れ試験 - 機器のラックマウント、LANケーブル敷設 - 回線敷設の立ち会い ### 取り組み - 構成図などの作成においては、特に依頼者側との意識の齟齬が発生しないように作成。 - キャリアとの調整に当たり、キャリアバンドルルータを利用したケースでは、設定内容や試験内容の要望をベンダーと意識あわせをするが、そこで意識の齟齬が発生しないように対応。 - 依頼者側は社内の他事業部ということもあり、責任分界点が曖昧になりがち。 進捗会議では曖昧になりそうな点（タスクや責任分界点など）を明確にして表現するように留意して進めた。 - 既存回線の更改というケースでは、、移行中におけるシステムへの影響範囲が極小化されるように、複数回線を段階的にリリースをした。 ### 発生した問題と、それに対する対応 - 台風直撃に伴うNW器機製造工場の水没により器機調達が難航。 それによる移行方式の再設計などもあったが、キャリアと調整をし、無事にリリースへこぎ着けた。 具体的には、回線を敷設する際のキャリア側の局舎を、当初の予定から変更すると行ったやりかたで対応した。 回線の局舎により、使用できる、あるいはマウントされている機器が異なるため、調達が困難となった機器がマウントされている局舎を見つけてもらい、対応した。 --- ## 2. 追加されたサービスや機器に関しての運用担当引継ぎ ### 概要 - 故障発生時の手順書作成 - 設計書の修正 - 追加されたサービスや機器の説明 - 追加されたサービスや機器が故障、トラブルが発生した場合の手順や、影響調査方法の説明 - 監視システムへの機器情報登録 ### 使用した環境・技術 - Excel - PowerPoint - Word ### 課題・問題点 - サービスや機器が追加された場合、故障時の対応を運用担当へ引き継ぐ必要がある。 そのためにドキュメントを作成し、故障時の対応方法、ベンダーへの連絡先、エスカレーション方法などを、運用担当へ引き継ぐ。 ### 取り組み - 運用手順作成、故障陣対応方法引継ぎ。 - 移行期間中における、留意事項などを引き継ぎ。

# プロジェクト概要 ## 目的、背景 - 金融機関向けサービスを提供するためのネットワーク機器設定変更 - 故障対応やネットワークトラフィック分析 - 新規サービス追加時の運用引継ぎ - 金融機関からの問い合わせ対応（メールによる対応） ## 期間・チーム構成 2015/04〜2019/09 - 10人程度のチーム 所属するグループは30人程度で構成 ## 担当した役割 - 機器設定変更、リリース作業 - 作業の改善や故障対応 - 自社のメンバーの管理（常時約5人ほどが、入れ替わり立ち替わり） - 自社のエンジニア採用業務 ## プロジェクトに関連する資格・認定 - [Cisco Certified Network Professional Routing and Switching (CCNP Routing and Switching)](https://www.credly.com/badges/b26fee92-444d-4945-812c-0d5e27e101de)（2023年現在はEXPIRED） - [Cisco Certified Network Associate Routing and Switching (CCNA Routing and Switching)](https://www.credly.com/badges/a25336c0-24e6-476a-abe5-5c27c92887fc)（2023年現在はEXPIRED） - EXCEL-VBAエキスパート(ベーシック) # タスク内容 --- ## 1. 金融機関向けネットワーク機器の設置及び設定変更 ### 概要 - 金融機関からサービスの新規追加や変更、及び削除のオーダーを受領した場合における、ネットワーク機器への設定変更 - Configを作成する元ネタとなるパラメーターシートの作成 - ネットワーク機器へ反映するConfig作成と、Configレビューの実施 - 金融機関向けのサービスということもあり、成果物やリリース作業は、高い品質が求められる。ちょっとしたミスも原因究明と再発防止の施策を求められ、その後の作業ボリュームが増すという状況に陥っていた。 故障が発生しサービス影響が出れば、金融機関は金融庁への報告が発生するケースもあるため、常に緊張感をもって持って対応をしていた。 ### 使用した環境・技術 - cisco (L2sw, L3sw, Router) - 帯域制御装置（bluecoat社PacketShaper） - Redmine - Excel VBA - RHEL ### 課題・問題点 - 各種ネットワーク機器のパラメータシート、Configの作成。 しかしパラメータ数が多く、作成に時間を要した。また、ミスも散見された。 - 作成されたConfigのチーム内レビューの実施。 複数人で対面のレビューをするものの、いくら丁寧にレビューをしても、メンバーのスキルや繁忙期の物量次第では、ミスがゼロにする事が難しい。 また、人員不足から、スキルの低い新人がアサインされるケースが増えたことも重なり、品質が劣化しているという側面もあった。 - 試験環境へConfigを反映し、試験を実施 ### 取り組み - 金融機関からのオーダーや現行のConfigをインプットとし、パラメーターシートを作成するツールをVBA（Excel）で作成。可能な限り手作業を減らすことを試みた。 ### 工夫した点 - 私が着任した時点で、一部はツール化されていたものの、複数のツールがあることと、手動で値を入れる箇所が多くミスを誘発していた。そのため、既存のツールを流用しながらも、手動入力の部分は可能な限り減らし、ツールの数も1つ、オーダによっては2つ程度まで抑えた。 これにより、1つのオーダーで4時間程度掛かっていたパラメーターシートの作成が、30分程度まで削減できた。 - ツールで自動化を進めたことで、成果物の品質も向上した。しかし功罪の「罪」の部分として、新規で着任してくるメンバーのスキルが向上しないという側面が現れた。これについては、対面のレビューの際にフォローアップをするなどして対応した。 --- ## 2. 運用引継ぎ業務 ### 概要 - 金融機関向けのネットワーク機器の設定変更や、新しいサービスが追加される場合において、運用担当へ引継ぎを行う。 引継ぎ内容は、サービスを維持するための定常作業や、故障時のトラブルシューティング方法。エスカレーション先など。 ### 使用した環境・技術 - Word - Excel ### 課題・問題点 - 運用引継ぎに向けて、手順書や故障時の振る舞いをまとめたドキュメントを作成する必要あり。 運用担当の作業量が増えたり、故障時のトラブルシューティングが複雑だと、運用担当が受け入れを拒否する。そのため、定常作業は可能な限りの自動化であったり、手順の手数を減らすことを目指し、故障時の振る舞いはシンプルな内容にする必要があった。 - 運用引継ぎに当たっては、運用担当の部課長へ説明する必要があり、そのための説明資料を作成。 ### 取り組み - サービス（サーバー）を提供する部署と連携し、サービスの特性、ネットワークの構成を確認し、仕様を把握する。 - 運用担当への正式な引き継ぎの前に、何度か運用担当と打合せを行い、意識合わせを行う。要望があれば吸い上げ、ドキュメントへ反映させる。 - 運用担当とは様々なサービスの故障対応時などでも会話をしているので、日頃からコミュニケーションを行うことで、いざ運用引継ぎを行うときにスムーズに話すが進むこともある。あと、仲良くなっておくと、いざ障害が発生したときなどに、運用担当に対する作業依頼に融通が利きやすくなる。 --- ## 3. 金融機関向け回線のトラフィック分析ツール作成（Excel VBA） ### 概要 - ネットワーク機器からテキストで出力されたトラフィックデータを集計するツールをExcel VBAで作成。 - ツールの使い道としては、ネットワーク回線に以上が見られた際の分析であったり、センタ〜金融機関の間の回線を速したり減速させたりする際の判断材料となる。 ### 使用した環境・技術 - Excel VBA ### 課題・問題点 - テキストで出力されたファイル数は、1分間に1ファイル、且つネットワーク機器ごとに生成される。そのため、処理をする対象のファイルの数が多い。 - 金融機関から提出を求められれば応じる必要があるため、体裁は整える必要があった。 ### 取り組み - Excel VBAを使い、データを集計し、グラフ化するツールを作成した。 ### 工夫した点 - Excel VBAの特徴として、シートやセルを使用する作りをするとかなり動作が遅くなるので、必要な場合以外はシートやセルに出力しないような作りをした。 - 構造体や連想配列などを使い極力メモリで処理することで、処理速度の向上に努めた。 --- ## 4. リリース作業 ### 概要 - ネットワーク機器への設定変更作業 - リリース作業のドキュメント作成（手順書、タイムテーブルなど） - リリース判定、品質判定会議 - 作業当日のタスクとスケジュール管理 ### 使用した環境・技術 - Excel - Word - Linux ### 取り組み - 設定変更を担当する作業者と連絡を取りつつ、タイムテーブルを管理する。 - トラブルが発生すれば、トラブルシューティングを行う。サービスに影響を及ぼす可能性が出てきた場合は、上長へエスカレーションをする。 ### 工夫した点 - 作業中、あるいは作業後に故障が発生することがあったため、作業用のドキュメントだけでなく、故障切り分けに必要となり得るドキュメントを印刷し、作業区画に持ち込んでいた。 （作業区画はファイルサーバーに接続できないため、紙を印刷する必要があった） --- ## 5. 自社メンバー採用業務 ### 概要 - エンジニア採用業務 - 現場業務のOJT - 1 on 1 ### 取り組み - 役職に就いた頃から採用面接の対応をするようになったが、面接をされるよりも緊張してしまったりもしたので、採用に関する書籍などを買い漁って勉強した。 分かったことは、面接はする方もされる方も、評価され、値踏みされているということ。 自社の魅力を伝えることに、とても苦労をした。 - 当時所属していた会社は、お世辞にもよい会社ではなかったこともあり、エンジニア採用は難航していた。 とりわけ2010年代後半から如実に、面接希望者の品質が劣化し始めていた。 いわゆる「デジタルネイティブ世代」あたりが、スマホを当たり前のように使っている反面、キーボードのブラインドタッチができないというケースが散見されるようになったときは、さすがに危機感を覚えた。 入社される社員のスキルレベルがあまりにも低すぎると、着任した先でフォローアップをする社員の負荷が高まる。そして、既存社員の不満が募り退職していく、という悪循環。 1on1などの面談の場などでも、口癖のように「もう辞める」と口にするメンバーが増えてきた。 不満の原因は明らかで、現場のローテーションがなされないことと、新人のフォローに疲弊していた。 そのことを上長や部長クラスに提言するものの、改善されることはなかった。