WHI_developersBoost2020登壇資料

Slide 1

Slide 1 text

古の大企業向けパッケージソフトのクラウド移行に Joinして見えた面白さ増井秀和 / Hidekazu Masui Dec 12, 2020 @ Developers Boost 2020 #devboost / Session 2

Slide 2

Slide 2 text

1. 自己紹介 2. 持ち帰ってほしいこと 3. 古のアプリの紹介 4. クラウド移行にJoinしてみた 5. まとめ Agenda 2

Slide 3

Slide 3 text

● SREやってます ⇒ 運用・監視・構成管理(Ansible) ● AWS詳しいです ⇒ Solution Architect Proﬀessionalの資格を取得しています ⇒ EC2 / ELB(ALB) / SSM / ECS / Aurora etc.. ● 最近副業はじめました ⇒ 副業では本業ではあまり触れない ⇒ Ruby On Rails・AWS IoTなどいろいろ勉強中 ● 趣味はダーツ・弓道など ⇒ 狙う系がなぜか好き自己紹介 3

Slide 4

Slide 4 text

好きな言葉 4 ねだるな　勝ち取れ　　さすれば与えられん

Slide 5

Slide 5 text

持ち帰って欲しいこと 5 レガシーアプリの可能性クラウドエンジニアリングの面白さアプリケーションのクラウド化の価値エンジニアとして難題に取り組むことによるメリット仕事の面白さ

Slide 6

Slide 6 text

“ 6 古のアプリの紹介

Slide 7

Slide 7 text

COMPANYとは 7 1996 年に誕生 24 年目を迎えた歴史あるアプリ 1100 社を超える大企業が使用ノーカスタマイズで同一コードを全社で使用

Slide 8

Slide 8 text

製品概要 COMPANY Web Service  は身上届や年末調整申告など従業員からの申請や給与明細等の照会をWeb上で実現することで、業務効率化・ペーパレス化を推進。人事データベースとシームレスに連携し、リアルタイムな人材情報の照会を実現。  COMPANY 人事・給与  はグループ関連会社を含めた人事情報の一元管理、各企業・法人の給与計算（複雑な手当や日本独自の福利厚生）に対応することで、既存業務の効率化および活用のための人材情報の蓄積を実現。  COMPANY 就労・プロジェクト管理  は多様な勤務体系・雇用形態への対応はもちろん、36協定管理、  リアルタイムな勤怠集計や通知など、労務管理レベルの向上を実現。 

Slide 9

Slide 9 text

製品概要 COMPANY HR Series  日本の大手法人の人事関連業務をサポートする  サービスです。  ● 1,100法人以上のユーザー様の業務ノウハウを集約した統合型人事システム。  ● 多種多様なお客様の業務に柔軟に対応できるよう、幅広く機能を揃えています。  ● HRシステム市場シェアNo.1獲得 

Slide 10

Slide 10 text

製品概要 COMPANY Talent Management  は人材育成のための教育・研修業務の効率化から、全社の人材情報を  俯瞰して分析を可能とすることで、次世代リーダーの早期発掘、後継者の育成など、戦略的な人材活用マネジメントを実現。  COMPANY Identity Management  は社内システムのID統合管理を支援することで、セキュリティレベルの向上と、ID管理運用の適正化を実現。 

Slide 11

Slide 11 text

製品ラインナップ 11

Slide 12

Slide 12 text

業種・業態を問わず、数千名～数万名規模の大手法人にご利用いただいています  実績従業員数 3,000人以上  国内大手企業の 3社に1社が当社のHR製品を利用（当社調べ）  人事データ数   410万人 ※  顧客数  1,100 法人グループ超  ※2019年10月末時点ライセンス数より換算 

Slide 13

Slide 13 text

～ノーカスタマイズ～弊社独自の開発手法  A法人  B法人  C法人  あらゆる業種業界の  業務要件を  標準機能にて開発  豊富な機能の中から  ニーズに合った使い方で  選んで使っていただく  製造業メディア   通信業界石油事業自動車   関連業電鉄業卸売事業法制度への対応  通常のパッケージ開発  企業で共通して必要となる  機能を標準機能化    特有の要件は個社個別の  アドオン開発にて実装  業務改善や組織変更等への対応は  再構築の必要が生じてしまう  変化に対して柔軟な対応ができず   対応するにもコストとのトレードオフが発生  金融業   13 多種多様な業界に必要な業務を23年間に渡り標準化し続けてきました  変化に対して柔軟な対応が実現できるため  継続的な業務改善が可能 

Slide 14

Slide 14 text

業種・業態を問わず、大手1,100法人以上にご利用いただいています  導入実績例（一部） 14 製造業  建設業  学校法人  その他  小売業  銀行業  情報・通信業  社会福祉法人  自治体 

Slide 15

Slide 15 text

クラウドサービス化を実施中 15

Slide 16

Slide 16 text

クラウドインフラ構成 16

Slide 17

Slide 17 text

COMPANYとは 17 1996年に誕生 24年目を迎えた歴史あるアプリ 1100社を超える大企業が使用ノーカスタマイズで同一コードを全社で使用

Slide 18

Slide 18 text

COMPANYとは 18 1996年に誕生 →オンプレミスの 24年目を迎えた歴史あるアプリ →レガシーアプリで 1100社を超える大企業が使用ノーカスタマイズで同一コードを全社で使用 →膨大なコード量・各機能同士の密接な関連

Slide 19

Slide 19 text

エピソード紹介 19 数時間ダウンタイムを伴うdeploy作業 Java6で書かれている 320万を超えるコード量 1,2年前はビルドに4時間かかっていた (現在は50分程度に短縮されている ) デリバリー前にかかる膨大な確認工数 Preparationと呼ばれる一大事業

Slide 20

Slide 20 text

“ クラウド移行にJoinしてみた 20

Slide 21

Slide 21 text

今回の対応箇所 21

Slide 22

Slide 22 text

今回の対応箇所 22

Slide 23

Slide 23 text

今回の対応箇所 23

Slide 24

Slide 24 text

AWS触ってきた経験をアプリ側に活かしたい ⇒ いままでの経験を試したい ECS触ってみたい ⇒ 新しいスキル・知見を得たい今後のプロダクトの発展に貢献したい ⇒ 影響力のある仕事をしたいどうしてJoinしたの？ 24

Slide 25

Slide 25 text

バッチジョブ実行の流れ 1. APサーバーがジョブキュー (DBのテーブル) にジョブを投入する  2. CJK BS内のサービス (RemoteJobService) が定期的にDBの  テーブルを読み、ジョブを取得する  3. 未処理のジョブがあれば、CJK BS内でジョブを実行する (BatchExecutor)  4. ジョブ実行結果をDBに書き込む現行アーキテクチャと問題点 25

Slide 26

Slide 26 text

現行アーキテクチャと問題点 26 問題点 ● 高負荷でメモリなどが枯渇することがある ● 負荷への対策がスケールアップしかないすなわち、ダウンタイムを伴う ● 稼働状況によらず一定のコストが掛かる (BS: m5.large ～ m5.2xlarge程度)

Slide 27

Slide 27 text

1. 新しいサービスのキャッチアップ 2. 巨大なアプリの基盤を変えるということ 3. アプリの開発者とのスキルセットのすり合わせ 4. 既存の機能をクラウドに置き換えても担保する必要があること課題 27

Slide 28

Slide 28 text

1. 新しいサービスのキャッチアップ 2. 巨大なアプリの基盤を変えるということ 3. アプリの開発者とのスキルセットのすり合わせ 4. 既存の機能をクラウドに置き換えても担保する必要があること課題 28

Slide 29

Slide 29 text

1. 新しいサービスのキャッチアップ 2. 巨大なアプリの基盤を変えるということ 3. アプリの開発者とのスキルセットのすり合わせ 4. 既存の機能をクラウドに置き換えても担保する必要があること課題 29

Slide 30

Slide 30 text

● SlackでRSS Appを使用 ● 専用のチャンネルを作成し、AWS関連のブログ記事・機能追加のフィードを購読 ● 手に入れた情報はすぐに手を動かして試すインプット習慣を作る 30

Slide 31

Slide 31 text

インプット習慣を作る 31

Slide 32

Slide 32 text

インプット習慣を作る 32 ● チェックしたものを後から見返せるようにしたい ● リアクションをつけると別チャンネルに投稿される仕組み. ● Reacji ChannelerとかでもOK

Slide 33

Slide 33 text

1. 新しいサービスのキャッチアップ 2. 巨大なアプリの基盤を変えるということ 3. アプリの開発者とのスキルセットのすり合わせ 4. 既存の機能をクラウドに置き換えても担保する必要があること課題 33

Slide 34

Slide 34 text

既存機能の担保 34

Slide 35

Slide 35 text

● バッチの実行中のLOGをアプリケーションからダウンロードできる機能がある ● その機能を担保しなくてはいけない ● LOGは基本的にCloudwatch Logsへ行く ● 同様の機能を実現するには、半リアルタイムでCloudwatch Logsからデータを取ってこないといけない. でもこれが結構大変既存機能の担保？

Slide 36

Slide 36 text

● CloudwatchからS3エクスポート機能⇒S3⇒アプリケーションでダウンロード案１

Slide 37

Slide 37 text

● CloudwatchからS3エクスポート機能⇒S3⇒アプリケーションでダウンロード案１エクスポート機能はバッチ的な実行なので、リアルタイムでS3には上げられない

Slide 38

Slide 38 text

● Kinessis Firehose -> S3 -> アプリケーションでダウンロード案２

Slide 39

Slide 39 text

● Kinessis Firehose -> S3 -> アプリケーションでダウンロード案２ Kinesis利用によるコスト増・構成の複雑化現在と同様のLOG形式にするには、ストリーミング時にLambdaでデータを成形する必要ありこの機能を担保するだけなのに多すぎる構成変更

Slide 40

Slide 40 text

● サイドカーでfluentdコンテナ -> S3 -> アプリケーションでダウンロード案３

Slide 41

Slide 41 text

● サイドカーでfluentdコンテナ -> S3 -> アプリケーションでダウンロード案３起動コンテナが増えることによるコスト増

Slide 42

Slide 42 text

● fargateからEFSに実行LOGファイルを出力する ● 最小限の変更で済む、理想の形案４

Slide 43

Slide 43 text

● fargateからEFSに実行LOGファイルを出力する ● 最小限の変更で済む、理想の形案４ fargateではEFSのマウントが対応してない (EC2 ECSでは対応している)

Slide 44

Slide 44 text

Slide 45

Slide 45 text

● AWSサポートへの問い合わせ ● 今の要件を伝えて実現方法の相談 ● 機能要望の提案 ● ロードマップの確認 ● 暫定的な対応と恒久的な対応を検討理想の形を描きながら、今できること 45

Slide 46

Slide 46 text

ロードマップを見てみる 46

Slide 47

Slide 47 text

● AWSサポートへの問い合わせ ● 今の要件を伝えて実現方法の相談 ● 機能要望の提案 ● ロードマップの確認 ● 暫定的な対応と恒久的な対応を検討キャッチアップの習慣が活きる 47

Slide 48

Slide 48 text

● AWSサポートへの問い合わせ ● 今の要件を伝えて実現方法の相談 ● 機能要望の提案 ● ロードマップの確認 ● 暫定的な対応と恒久的な対応を検討キャッチアップの習慣が活きる 48 FargateとEFSマウント機能の追加を発表初日でキャッチし、導入可能であることを確認

Slide 49

Slide 49 text

● インフラ構成は必ず自動化＝Infrastructure as Code ● EFSマウントは対応したが、Cloudfomationでは設定できない ● 作成済みのECSのTASKの情報を取得して、EFS 付きの設定で再作成する必要があり →スクリプトを作成して対応新機能の構成自動化 49

Slide 50

Slide 50 text

● 既存のバッチ実行サービスをECSに切り出し ● serviceにはせず、適宜ECS TASKを実行することで、コスト削減ポイント既存機能として存在するバッチLOG参照機能の担保 ● fargateにEFSをmountすることで、実行LOGをEFSへ出力、アプリケーションへの変更を最小限にして対応提案アーキテクチャ 50

Slide 51

Slide 51 text

今後のアーキテクチャイメージ 51 ● BS側にあるバッチ管理サービスをECSに移行して、BSサーバーを削除する  #devboost / Session2

Slide 52

Slide 52 text

新しいサービスのキャッチアップ巨大なアプリの基盤を変えるということアプリの開発者とのスキルセットのすり合わせ既存の機能をクラウドに置き換えても担保する必要があること課題 52

Slide 53

Slide 53 text

新しいサービスのキャッチアップ →インプット習慣の仕組み化巨大なアプリの基盤を変えるということ →望んでいた影響力のある仕事の実現今まで関わりが薄かった開発側の人とのコミュニケーション増アプリ開発者とのスキルセットのすり合わせ →自分より多くの経験を持つシニアエンジニアに対して Ownershipを持ってプロジェクトを進める経験既存の機能をクラウドに置き換えても担保する必要があること →AWSのサービスのフル活用座学ではわからない実用的な活用方法の経験課題＝自分の伸びしろ 53

Slide 54

Slide 54 text

54 まとめ

Slide 55

Slide 55 text

古いアプリケーションは、裏を返せば今でも生き残るニーズがあるということ時代の潮流に生き残ることは大変だが、その先の製品でハッピーになってくれる人がいるレガシーっていうけど 55

Slide 56

Slide 56 text

今のシェアを活かしつつ、さらにアプリケーションが持つ可能性を拡大「このプロダクトもっと面白くなる」という実感これから求められる知識を先取りできるまだまだオンプレミスアプリはエンタープライズの領域に存在そういったアプリのクラウド移行の需要は増していく難しい、けどそれが面白いもちろんはじめからクラウドネイティブなアプリも面白いそれより難易度は高いが、そこに面白さとニーズがあるクラウドネイティブ化の面白さ 56

Slide 57

Slide 57 text

エンジニアとしては難題の方が  経験になる    どれだけ他人に語れる経験ができたかがそのまま価値になるチャレンジ→悩む→後悔する  を超えた先難題と向き合うこと

Slide 58

Slide 58 text

「やる」きっかけを大切に 58 ● 12/01 社内で開催されたt_wada(和田卓人)さんのセッションでの話

Slide 59

Slide 59 text

引用資料 ● AWS シンプルアイコン - AWS アーキテクチャーセンター | AWS ● イラストや ● fluentd logo ● pixabay ● unsplash ● pakutaso ● oreilly [infrastructure as code] ● t_wadaさん・WHI用セッション資料 59 #devboost / Session2