Upgrade to Pro — share decks privately, control downloads, hide ads and more …

WHI_developersBoost2020登壇資料.pdf

2bcf696cd9cabc5b5cb0698b02f8dd15?s=47 WHIsaiyo
PRO
January 06, 2021

 WHI_developersBoost2020登壇資料.pdf

2bcf696cd9cabc5b5cb0698b02f8dd15?s=128

WHIsaiyo
PRO

January 06, 2021
Tweet

Transcript

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

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

    Agenda 2
  3. • SREやってます ⇒ 運用・監視・構成管理(Ansible) • AWS詳しいです ⇒ Solution Architect Proffessionalの資格を取得しています

    ⇒ EC2 / ELB(ALB) / SSM / ECS / Aurora etc.. • 最近副業はじめました ⇒ 副業では本業ではあまり触れない ⇒ Ruby On Rails・AWS IoTなどいろいろ勉強中 • 趣味はダーツ・弓道など ⇒ 狙う系がなぜか好き 自己紹介 3
  4. 好きな言葉 4 ねだるな  勝ち取れ   さすれば与えられん

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

  6. “ 6 古のアプリの紹介

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

  8. 製品概要 COMPANY Web Service
 は身上届や年末調整申告など従業員からの申請や給与明細等の照会をWeb上で 実現することで、業務効率化・ペーパレス化を推進。人事データベースとシームレ スに連携し、リアルタイムな人材情報の照会を実現。
 COMPANY 人事・給与
 はグループ関連会社を含めた人事情報の一元管理、各企業・法人の給与計算

    (複雑な手当や日本独自の福利厚生)に対応することで、既存業務の効率化およ び活用のための人材情報の蓄積を実現。
 COMPANY 就労・プロジェクト管理
 は多様な勤務体系・雇用形態への対応はもちろん、36協定管理、
 リアルタイムな勤怠集計や通知など、労務管理レベルの向上を実現。

  9. 製品概要 COMPANY HR Series
 日本の大手法人の人事関連業務をサポートする
 サービスです。
 • 1,100法人以上のユーザー様の業務ノウハウを集約した統合 型人事システム。
 •

    多種多様なお客様の業務に柔軟に対応できるよう、幅広く機 能を揃えています。
 • HRシステム市場シェアNo.1獲得

  10. 製品概要 COMPANY Talent Management
 は人材育成のための教育・研修業務の効率化から、全社の人材情報を
 俯瞰して分析を可能とすることで、次世代リーダーの早期発掘、後継者の育 成など、戦略的な人材活用マネジメントを実現。
 COMPANY Identity Management


    は社内システムのID統合管理を支援することで、セキュリティレベル の向上と、ID管理運用の適正化を実現。

  11. 製品ラインナップ 11

  12. 業種・業態を問わず、数千名~数万名規模の大手法人にご利用いただいています
 実績 従業員数 3,000人以上
 国内大手企業の 3社に1社 が当社のHR製品を 利用(当社調べ)
 人事データ数 


    410万人 ※
 顧客数
 1,100 法人グループ超
 ※2019年10月末時点 ライセンス数より換算

  13. ~ノーカスタマイズ~ 弊社独自の開発手法
 A法人
 B法人
 C法人
 あらゆる業種業界の
 業務要件を
 標準機能にて開発
 豊富な機能の中から
 ニーズに合った使い方で


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

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


    社会福祉法人
 自治体

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

  16. クラウドインフラ構成 16

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

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

  19. エピソード紹介 19 数時間ダウンタイム を伴うdeploy作業 Java6で書かれている 320万を超えるコード量 1,2年前はビルドに4時間 かかっていた (現在は50分程度に短縮されている )

    デリバリー前にかか る膨大な確認工数 Preparationと呼ばれ る一大事業
  20. “ クラウド移行にJoinしてみた 20

  21. 今回の対応箇所 21

  22. 今回の対応箇所 22

  23. 今回の対応箇所 23

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

    24
  25. バッチジョブ実行の流れ 1. APサーバーがジョブキュー (DBのテーブル) にジョブを投入する
 2. CJK BS内のサービス (RemoteJobService) が定期的にDBの


    テーブルを読み、ジョブを取得する
 3. 未処理のジョブがあれば、CJK BS内でジョブ を実行する (BatchExecutor)
 4. ジョブ実行結果をDBに書き込む 現行アーキテクチャと問題点 25
  26. 現行アーキテクチャと問題点 26 問題点 • 高負荷でメモリなどが枯渇することがある • 負荷への対策がスケールアップしかない すなわち、ダウンタイムを伴う • 稼働状況によらず一定のコストが掛かる

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

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

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

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

  31. インプット習慣を作る 31

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

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

  34. 既存機能の担保 34

  35. • バッチの実行中のLOGを アプリケーションからダウンロードできる機 能がある • その機能を担保しなくてはいけない • LOGは基本的にCloudwatch Logsへ行く •

    同様の機能を実現するには、 半リアルタイムでCloudwatch Logsから データを取ってこないといけない. でもこれが結構大変 既存機能の担保 ?
  36. • CloudwatchからS3エクスポート機能⇒S3⇒アプリケーションでダウンロード 案1

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

  38. • Kinessis Firehose -> S3 -> アプリケーションでダウンロード 案2

  39. • Kinessis Firehose -> S3 -> アプリケーションでダウンロード 案2 Kinesis利用によるコスト増・構成の複雑化 現在と同様のLOG形式にするには、ストリーミング時にLambdaでデータを成形する

    必要あり この機能を担保するだけなのに多すぎる構成変更
  40. • サイドカーでfluentdコンテナ -> S3 -> アプリケーションでダウンロード 案3

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

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

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

  44. 44

  45. • AWSサポートへの問い合わせ • 今の要件を伝えて実現方法の相談 • 機能要望の提案 • ロードマップの確認 • 暫定的な対応と恒久的な対応を検討

    理想の形を描きながら、今できること 45
  46. ロードマップを見てみる 46

  47. • AWSサポートへの問い合わせ • 今の要件を伝えて実現方法の相談 • 機能要望の提案 • ロードマップの確認 • 暫定的な対応と恒久的な対応を検討

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

    キャッチアップの習慣が活きる 48 FargateとEFSマウント機能の追加を 発表初日でキャッチし、導入可能である ことを確認
  49. • インフラ構成は必ず自動化 =Infrastructure as Code • EFSマウントは対応したが、Cloudfomationでは 設定できない • 作成済みのECSのTASKの情報を取得して、EFS

    付きの設定で再作成する必要があり →スクリプトを作成して対応 新機能の構成自動化 49
  50. • 既存のバッチ実行サービスをECSに切 り出し • serviceにはせず、適宜ECS TASKを実 行することで、コスト削減 ポイント 既存機能として存在するバッチLOG参 照機能の担保

    • fargateにEFSをmountすることで、実 行LOGをEFSへ出力、アプリケーション への変更を最小限にして対応 提案アーキテクチャ 50
  51. 今後のアーキテクチャイメージ 51 • BS側にあるバッチ管理サービスをECSに移行して、BSサーバーを削除する
 #devboost / Session2

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

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

    座学ではわからない実用的な活用方法の経験 課題=自分の伸びしろ 53
  54. 54 まとめ

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

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

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

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

  59. 引用資料 • AWS シンプルアイコン - AWS アーキテクチャーセンター | AWS •

    イラストや • fluentd logo • pixabay • unsplash • pakutaso • oreilly [infrastructure as code] • t_wadaさん・WHI用セッション資料 59 #devboost / Session2
  60. © 2020 Works Human Intelligence Co., Ltd.
 Strictly Confidential
 60