WHI_developersBoost2020登壇資料

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. 製品概要
   COMPANY Web Service

   は身上届や年末調整申告など従業員からの申請や給与明細等の照会をWeb上で
   実現することで、業務効率化・ペーパレス化を推進。人事データベースとシームレ
   スに連携し、リアルタイムな人材情報の照会を実現。

   COMPANY 人事・給与

   はグループ関連会社を含めた人事情報の一元管理、各企業・法人の給与計算
   （複雑な手当や日本独自の福利厚生）に対応することで、既存業務の効率化およ
   び活用のための人材情報の蓄積を実現。

   COMPANY 就労・プロジェクト管理

   は多様な勤務体系・雇用形態への対応はもちろん、36協定管理、

   リアルタイムな勤怠集計や通知など、労務管理レベルの向上を実現。

   

   View Slide

9. 製品概要
   COMPANY HR Series

   日本の大手法人の人事関連業務をサポートする

   サービスです。

   ● 1,100法人以上のユーザー様の業務ノウハウを集約した統合
   型人事システム。

   ● 多種多様なお客様の業務に柔軟に対応できるよう、幅広く機
   能を揃えています。

   ● HRシステム市場シェアNo.1獲得

   

   View Slide

10. 製品概要
    COMPANY Talent Management

    は人材育成のための教育・研修業務の効率化から、全社の人材情報を

    俯瞰して分析を可能とすることで、次世代リーダーの早期発掘、後継者の育
    成など、戦略的な人材活用マネジメントを実現。

    COMPANY Identity Management

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

    

    View Slide

11. 製品ラインナップ
    11
    

    View Slide

12. 業種・業態を問わず、数千名～数万名規模の大手法人にご利用いただいています

    実績
    従業員数 3,000人以上

    国内大手企業の 3社に1社 が当社のHR製品を
    利用（当社調べ）

    人事データ数
    

    410万人 ※

    顧客数

    1,100 法人グループ超

    ※2019年10月末時点 ライセンス数より換算

    

    View Slide

13. ～ノーカスタマイズ～
    弊社独自の開発手法

    A法人

    B法人

    C法人

    あらゆる業種業界の

    業務要件を

    標準機能にて開発

    豊富な機能の中から

    ニーズに合った使い方で

    選んで使っていただく

    製造業
    メディア 

    通信業界
    石油事業
    自動車 

    関連業
    電鉄業
    卸売事業
    法制度への対応

    通常のパッケージ開発

    企業で共通して必要となる

    機能を標準機能化

    

    特有の要件は個社個別の

    アドオン開発にて実装
 業務改善や組織変更等への対応は

    再構築の必要が生じてしまう

    変化に対して柔軟な対応ができず 

    対応するにもコストとのトレードオフ が発生

    金融業 

    13
    多種多様な業界に必要な業務を23年間に渡り標準化し続けてきました

    変化に対して柔軟な対応が実現できる ため

    継続的な業務改善が可能

    

    View Slide

14. 業種・業態を問わず、大手1,100法人以上にご利用いただいています

    導入実績例（一部）
    14
    製造業
 建設業
 学校法人

    その他

    小売業

    銀行業

    情報・通信業

    社会福祉法人

    自治体

    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

21. 今回の対応箇所
    21
    

    View Slide

22. 今回の対応箇所
    22
    

    View Slide

23. 今回の対応箇所
    23
    

    View Slide

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

    View Slide

25. バッチジョブ実行の流れ
    1. APサーバーがジョブキュー (DBのテーブル)
    にジョブを投入する

    2. CJK BS内のサービス (RemoteJobService)
    が定期的にDBの

    テーブルを読み、ジョブを取得する

    3. 未処理のジョブがあれば、CJK BS内でジョブ
    を実行する (BatchExecutor)

    4. ジョブ実行結果をDBに書き込む
    現行アーキテクチャと問題点
    25
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. 既存機能の担保
    34
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

44. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    #devboost / Session2
    

    View Slide

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

    View Slide

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

    View Slide

54. 54
    まとめ
    

    View Slide

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

    View Slide

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

    View Slide

57. エンジニアとしては難題の方が

    経験になる

    

    どれだけ他人に語れる経験ができたかが
    そのまま価値になる
    チャレンジ→悩む→後悔する

    を超えた先
    難題と向き合うこと
    

    View Slide

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

    View Slide

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

    View Slide

60. © 2020 Works Human Intelligence Co., Ltd.

    Strictly Confidential

    60

    

    View Slide