協和キリンのAWS活用事例
楠本貴幸氏：みなさん、こんにちは。協和キリンICTソリューション部・企画管理グループの楠本といいます。本日はご視聴いただき誠にありがとうございます。本日は、弊社からAmazon WorkSpacesを活用した事例についてご紹介させていただきます。
では、さっそく内容に入っていきたいと思います。本日のタイトルは「ライフサイエンス業界におけるAmazon WorkSpaces活用事例」ということで、私、楠本と、弊社ICTソリューション部・田中とともに、事例の紹介をさせていただきたいと思います。
KKC（Kyowa Kirin Co.,Ltd.）のAWSの事例紹介は、これまで「AWS Summit」やほかのイベントで話をさせていただいているので、すでにご存知の方もいらっしゃるかもしれませんが、今回はこれまであまり話してこれなかった具体的なWorkSpacesの導入背景から運用、及びCOVID-19での対応などについて、どのような考えで実施し実現させていったかという話を中心にお話しいたします。
本日のアジェンダについてですが、まずは弊社の紹介。そして、KKCのクラウド戦略やアーキテクチャの紹介を私からさせていただいて、AWSの活用状況だけではなく、WorkSpacesに関した紹介をいたします。その中では、導入状況や、運用して良かった点・苦労した点……まあ、苦労した点が多くなるかもしれませんが、そういった点と、あとは具体的なケースについても説明させていただきます。
続きまして、弊社の紹介をさせていただきます。まず協和キリンの会社紹介です。協和キリンは1949年7月1日に旧協和発酵工業として創業し、2008年の10月1日付でキリンファーマ株式会社との合併により協和発酵キリンとなりました。2019年1月1日に現在の社名である協和キリン株式会社に社名変更しております。
親会社はキリンホールディングスで、その中の製薬を担っている会社となります。弊社の経営理念は「協和キリングループは、ライフサイエンスとテクノロジーの進歩を追求し、新しい価値の創造により、世界の人々の健康と豊かさに貢献します」というところです。
少し具体的な数字についても紹介します。いずれの数字も2019年12月の情報となりますが、従業員数が5,267名、売上高が3,058億円、海外売上高比率が約39パーセントの会社となります。会社としては海外での新薬の上市もあり、急激に海外展開を進めている状況となっております。
“クラウド化”は目的ではない
それではここから、少し具体的な話をさせていただきます。こちらが私からのキーメッセージとなりますが、主に2つあります。1つが、簡単に言ってしまうと「クラウド化というのは目的ではなくて、ビジネスを推進することが目的である」ということ。もう1つは「リスクをとって、少しずつでも前に進んでいく必要性がある」ということです。
まず、クラウド化で一番大事なものは「目的を明確にする」ことなんですが、よく勘違いされているのは、いつのまにか「クラウド化すること」が目的となってしまって、手段と目的が逆転するということがあります。最終的な目的は、特にユーザー企業にとっては、やはりビジネスを推進させることであって、そのためにリソースを振り向けるべきところに振り向けられる体制を持っていく。そのための手段としてクラウドを活用していく、ということがあります。
もう1つ、リスクに関してです。変化に対する漠然とした不安が変化することを躊躇させますが、今の時代は変わらないこと自体がリスクでもありますし、変化しないことがやがて大きなリスクとなることを理解しておくことが必要であると考えています。
次ですが、ここ最近の大きなトレンドとして、IT組織に求められる役割が大きく変わってきていると感じています。これまでの国内基幹系を中心とした既存のサービス範囲であれば、もちろんオンプレミスでの対応も可能だったと思います。今でもそうかもしれません。
ただし、グローバルへのサービス拡大であったり、最新の技術を用いたデジタル推進を実現しようとした際、「ビジネスのグローバル化」や「デジタル化」など言葉にすると単純ですが、実際の業務に落とし込んでいくとかなりのステップアップが必要となります。
これらの要求に応えるには、クラウドの活用は必須となってきていますし、逆にクラウドの環境がないとこのような対応はできないと言っても過言ではないと考えています。
そういう背景のもと、我々協和キリンがどのようなかたちでクラウドジャーニーを歩んできたかについて簡単に説明させていただきます。
AWS利用開始から7年での変化
我々が最初にクラウドを利用し始めたのは、2012年のMAID環境の移行からです。2013年にはAWSをIaaSのプラットフォームとして正式に採用し、クラウドファースト宣言のもと、これまで多くのシステムをAWSへ移行してきました。
ただし、我々の戦略としては、SaaSを第一選択肢として、SaaSでサービスが選択できないものについてはAWSのIaaSを活用してシステムを展開するようにしています。
また、2018年からはイノベーションへの挑戦ということで、新しい技術を使った業務の高度化や、生産性の向上を目標に活動しております。
ここで、KKCのアーキテクチャの大まかな概要を説明させていただきます。ポイントとしては、自ら作り出すのではなく、すでに存在するサービスを組み合わせながらいかに有効にそれらを利用していくのか。各サービスのメリットを活かしながら、最適なアーキテクチャを採用するということになります。自社に最適なサービスを採用しつつも、会社全体として業務が止まらないアーキテクチャを採用することも目指しています。
その1つが、本日ご紹介する「Amazon WorkSpaces」の導入です。例えば、Amazon WorkSpacesを含めたシステム基盤として利用しているAWSとコミュニケーションのプラットフォームをあえて別にしています。これはシステムが停止してもメールで業務が継続できることもありますし、逆のパターンも当てはまると考えています。
マルチクラウドについては常に意識はしていますが、IaaSの領域のマルチクラウドというよりも「ビジネスを止めない」という意味での、広い意味でのマルチクラウドの採用を進めている状況です。
次は、2013年から開始したクラウド活用の結果、現在までにどのような変化が起きたかを簡単に共有させていただきます。
まずは、データセンターにおける基幹系システムの稼働はゼロとなりました。これは、AWSへの移行もありますが、SaaSへの移行を含めての結果となります。また、CSV対象システムも、データセンターで最後の1システムが稼働しているのみとなっており、データセンターに設置しているサーバー群の移行はほぼ完了している状況となっています。利用金額の詳細については割愛しますが、利用開始時と比較して約15倍となっており、着実にAWSを利用しているような状況です。
WorkSpacesについては、2013年はサービスがなかったんですが、徐々にその台数を増やしてきており、今回のCOVID-19の関係もあって、今は約2,000台の導入をしているような状況です。
こうして7年にわたりAWSを活用した結果、今どういうことになっているかというと、一番の大きな変化は、ビジネス部門でも「AWSにシステムが載っていないということがリスク」という認識が一般的になってきています。また、AWSとは直接関係ないかもしれませんが、SaaSをノンカスタマイズで利用するというクラウドネイティブの志向もかなり浸透してきている状況です。
ICTソリューション部の視点で見ると、これまでの運用管理要員を、ソリューション企画要員にシフトできつつある状況は、大きなメリットの1つと考えています。
WorkSpacesの導入目的と用途
次はWorkSpacesの導入目的および現在の利用用途について説明させていただきます。
VDIの導入の背景は、もともとはセキュリティの強化から始まっています。そのために、最初に社内の重要なデータにアクセスするメンバーに対してAmazon WorkSpacesの導入を行いました。その後、働き方改革の推進もあり、対象ユーザーを増やしていきました。現在は、事業継続性のために利用用途が拡大しています。特に今回のCOVID-19により、利用者が急激に増加しているという状況です。
では、なぜAmazon WorkSpacesを選択したかということなんですが、選択した理由は複数あります。主要なものとしては、やはり契約の柔軟性。それから、マネージドサービスであるための新機能の追加及び運用負荷軽減。そして、AWSでほかのシステムを稼働させている点での親和性が主要な理由となります。特に契約の柔軟性のところは、今回のCOVID-19の影響を見ても、非常に良かったポイントかなと思っています。
ここまでが私が説明させていただくパートになります。WorkSpacesの利用・運用の事例紹介については、弊社・田中のほうにバトンタッチをして説明していただこうと思います。私からは以上となります。どうもありがとうございました。
WorkSpacesの運用をどう改善してきたか
田中幸代氏：改めまして、協和キリンICTソリューション部・インフラソリューショングループの田中と申します。ここから先は私からご紹介させていただきます。
当社でWorkSpacesを検討・導入してから約4年ほど経過しました。「WorkSpacesを採用したのに、運用は楽になっていない」というのが少し前までの感想でした。WorkSpacesの利用前にも自社設備によるVDIは一部展開していましたが、WorkSpacesに切り替えるにあたり「WorkSpacesにしたらなにもしなくてもいいのか」「WorkSpacesにしたのになんだか忙しいんだけど」「周辺の準備や運用・保守はどうしたらいいの？」といった期待と心配をしつつ、AWSエンタープライズサポートとの連携により数ヶ月で導入することができました。しかし、その後もさまざまな課題やトラブルを経験し、現在に至っています。
これらの体験談をもとに、当社でのWorkSpacesの導入から現在に至る過程と、どのように運用を改善していったかについて紹介していきます。
まず、WorkSpacesの導入状況です。自社設備によるVDIの見直しとして、当時はコスト面・運用保守の負荷軽減を目的として、クラウドVDIの検討をしてきました。複数の候補の中からWorkSpacesの評価を2016年に実施、実運用に問題ないと判断し、2017年に導入・展開を行いました。
当初は、セキュリティリスクを軽減する目的で、利用対象者を本社中心に業務上セキュリティ情報を扱う方、外出先でよく利用する方に限定した展開でしたが、翌年にはUSの子会社において、社員の入れ替えが多く、都度パソコンのセットアップが必要だった管理負荷を軽減したい目的で、展開をしていきました。また、国内子会社の会社譲渡による一時的な環境維持のための提供も開始しています。
昨年には国内でも、政府による新しい働き方の推進もあり、利用者を拡大し、この時すでに1,200台ほどの台数になっていました。そして今年、COVID-19による緊急事態宣言を受け、在宅勤務の環境整備のため、さらに一時利用としてWorkSpacesの展開をしており、現時点で約2,000台が利用されています。
この在宅環境の提供も、すでに整備されていた環境を持っていたこともあり、急な対応でも数百台の在宅環境を準備し、利用者がスムーズに自宅での業務を開始することができました。
このようにさまざまな背景がありましたが、いずれにしてもWorkSpacesを展開することで解決できています。当社ではWorkSpacesのみを展開していますが、利用するにあたり申請フローを確立しており、各部の責任者の承認を必要とし、申請書を提出する手続きをとっています。
会社支給のパソコンの仕様
WorkSpaces側の展開とともに準備を進めていかなくてはいけない点として、会社支給のパソコンをどういった仕様にしていくかという課題がありました。WorkSpacesを利用するにあたっては高スペックな端末は不要と判断しましたが、セキュリティ上の担保は必要となります。
初期導入時には手元側のパソコンにIoT端末を選択し、シンクライアント専用端末として準備を行いました。WorkSpacesへはインターネットアクセスができれば問題ないこともあり、必要最小限のスペックとなっています。また、Windows10のOSのロックダウン機能、こちらは再起動をするとデータが初期化される機能ですが、これを用いてデータ保存ができない仕組みとしました。
さらに、WorkSpacesのサインイン時には、個人ごとにスマホのMFAアプリやメールを使った本人認証の機能を設定して、セキュリティを確保することとしました。現在は、IoT端末に固執せず、手元側のパソコンの展開を継続しています。
これらの運用体制ですが、各AWSの専任の体制を設けていないため、WorkSpacesについてもほかの業務と掛け持ちをしています。実務担当者において全体方針の検討、協力会社によるマスターやCLIプログラムの対応、オペレーションにて申請受付業務を進めています。
このように少数での運用を維持するためには、保守リソースを確保するために少し便利にした機能がありますので、続いてご紹介していきます。
自社開発した管理の仕組み
導入当初はまだWorkSpacesの機能が充実されていなかったこともあり、自社開発した管理の仕組みを2つご紹介します。
1つ目は、WorkSpacesのOSがハングアップして起動できない場合に通常AWSの管理コンソールからしか再起動ができなかったため、CLIを利用して再起動用のプログラムを作成し、利用者自身で行えるように専用のサイトを作成しました。
このサイトでは、ワンタイムパスワードの発行やマニュアルの参照も同じ画面から操作できるものとし、時間外でも利用者自身で行えるようにしました。同時に、オペレーション業務においても、特定のオペレーションメンバーがサイトからWorkSpacesを作成したり削除できるように専用の画面を設けました。こちらも管理コンソールから実施できます。
2つ目の仕組みとして、日々増えていく環境に対し、当社ではADアカウント情報と連携しているため、ADアカウントの有効期限が切れる前にキャッチアップするためのログ情報を管理者宛てに通知する仕組みを構築しました。これにより、日々の台数も同時にチェックできるようにしています。
その後、WorkSpacesのサービスも増えていき、ユーザー側で再起動やインスタンスタイプの変更・再作成ができるリビルド機能といったユーザーセルフサービスがリリースされて、より便利になってきました。
そのほかにも当社保有しているBYOLライセンス、これは200台以上所有している場合はオリジナルのマスターを作成することができるライセンスですが、当初はマスター作成に1ヶ月以上かかっていたのを数時間でアップロードできる仕組みが提供されました。
さらには、リストアもできるようになり、導入当初に欲しかった機能がここ数年で充実してきました。以前よりAWS側へ要望を出してきたことが実現されつつあり、大変助かっています。
このようにして、必要な機能は自分たちで構築し、運用負荷を軽減し、少ないリソースで対応を継続しています。
OSアップデートの負担を減らすために
とはいえ、運用整備をしていっても、日々の変化に対応していく必要があります。避けられないものとして「OSのアップデート」があります。続いて、OSアップデートについて触れてまいります。
ご経験された方ならおわかりかと思いますが、OSのアップデートはIT担当者にとって大きな負担です。昨年の当社では、それまで使っていたWorkSpacesのOSをWindows7からWindows10へアップデートし、こちらは大きなイベントでした。当時は簡単には移行ができず、利用者への移行作業を軽くできないかAWSソリューションアーキテクトメンバーとも相談し、次のかたちで実施を行いました。
実施条件として、WorkSpacesで構成される同一ディレクトリには重複したアカウントの作成ができない制約があります。また、IT担当者としては利用者の負担を少なくしたい思いがあります。
そういった中での実現として、まず異なるディレクトリを作成し、1ユーザーにWindows7とWindows10の2つの環境を提供しました。部署ごとに1ヶ月の並行期間を設けて、データ移行をバッチコマンドで実施する環境を用意しました。
この方法では1ユーザーが2台所有するため一時的にコストはかかりますが、並行期間を設けることでサポートの維持、利用者の不安・負担を取り除き、IT側の基盤準備もAWS側で行うため意識する必要がなく提供することができました。
この時は準備期間も含め、半年で約600名の環境の移行を実施しています。もちろん1日に100台近くの環境を作成することもあったため、AWSの基盤準備のタイミングは連携しながら行うことで、スムーズに移行を完了することができました。
今後はこのようなOSアップデートはなくなりますが、Windows10の定期的なアップデートが必要になってきます。Windows10のアップデートについては、次のように実施を行っています。
当社ではSCCMを利用し、夜間の自動配信で対応をしています。必ずしもすべてが正常にアップデートできるわけでもないため、今年リリースされたMigration機能なども併用して、手動対応を行っています。まだ実施回数として多くはないため、今後に向けてスケジュールや台数の最適な適用方法を確認しながら、確実な方法を見極めていきたいと考えています。
同じような対応として、Windowsのセキュリティパッチの配布も適用しています。WorkSpacesには物理パソコンのような電源オフといった概念がないため、利用者の使い方によっては常時起動したままというケースがあり得ます。そうなるとセキュリティパッチが適用できないため、週1回強制的に再起動するプログラムを作成し、その間に適用させるという工夫をしています。
このような運用維持をしていますが、やはり障害というのは不定期にやってきます。続いて障害時の対応についてご紹介していきます。
障害発生への対応
昨年の事例ではありますが、当社でWorkSpacesに接続できないという大きなトラブルが3回発生しました。全員ではありませんが、サインインのタイミングであったり、特定の時間以降に接続できないといったトラブルです。
サインインができない状況というのは、プレゼンが必要な会議で資料にアクセスができない、今日締め切りの業務が行えない、役員がアクセスできないといったビジネス側のインパクトも大きく、早急に復旧をしないといけません。
「接続できない」という一報を受けた際は、各方面の調査を行い、代替手段を利用者に提供する必要があります。AWS側でなにかキャッチアップしている情報がないかを確認し、社内環境のネットワークに問題がないかを調査します。並行して、利用者には代替手段を提供し、業務継続ができるように暫定対応を行います。状況によってはWorkSpacesを作り直すといった手段の対応も必要となっておりました。
接続できないというと利用者が心配になるかもしれませんが、当社では不測の事態も想定した代替手段として次のように対応しています。
何度かトラブルを経験することで、接続できないパターンがある程度把握できたので、代替手段をスムーズに案内できるようになりました。不測の事態に備えてネットワークに接続できない、外出中・海外出張中の接続トラブルなどはゼロにすることはできません。だからといってこのWorkSpacesの利便性を失う必要はなく、代替手段・併用手段があることで、より確実なものになると考えます。
障害発生時のダウンタイムも状況によって把握することで、弊社の場合リビルドやリストアでは約30分で復旧、作り直しの場合はデータ復元含め約90分で対応ということも、ユーザーへアナウンスすることができます。
当社では接続ができないトラブルが発生した場合は、シンクライアント専用端末だけではなく、通常のFATパソコンも展開していることもあり、ローカルで利用してもらうといった対応や、手元側のパソコンでクラウドサービスへの接続を許可してメールなど最低限の利用を可能とする代替手段を提供しています。
今後はCloudWatchでのモニタリングが充実してきたこともあり、こういった監視を組み込み、状況をいち早くキャッチアップできるように検討を開始したいと考えています。
WorkSpacesを使った業務利用の活用事例
ここまで運用・障害対応のお話をしてきましたが、WorkSpacesを使った業務利用の活用事例を1つご紹介していきたいと思います。RPAをWorkSpacesで動かすという事例になります。
業務プロセスの高度化の目的として、複数のRPA基盤としてWorkSpacesを活用しています。なぜWorkSpacesかと言いますと、RPAを効率よく実行させるためには常時稼動しているパソコンを準備する必要がありました。
もちろんサーバー環境であれば常時稼働もできますが、RPAを実行する処理が一部正常に稼働しないこともあり、パソコン環境が必要となりました。WorkSpacesは常時稼動している環境であり、当社のコントロール配下であるためセキュアな状態で処理を実行することが可能です。
処理を夜間や早朝の業務時間外に実行させることにより、処理の待ち時間も削減できます。物理パソコンの手配や、維持管理に関わる余計なオーバーヘッドも削減できています。RPAを利用する環境として、WorkSpacesは非常に有効であると考えています。
現在の運用負荷軽減の課題
このようにして、WorkSpacesの個人利用だけではなく、活用を含めて利用していますが、当社が思うさらなる運用負荷軽減ができるのではないかという視点で、課題として3つまとめたものをご紹介していきます。
導入当初は自社設備から脱却することによるコスト削減・運用負荷の軽減が図られましたが、今回の段階では別の運用負荷が課題となってきています。
1つ目として、BYOLのオリジナルマスターは、展開時はユーザー側の設定が最小限で済むため便利なのですが、チューニングについてはWorkSpacesの独自の部分もあるため、少しノウハウが必要となっています。そのためOSアップグレードのたびに必要な設定確認と検証が発生し、マスター作成の準備時間を必要とします。
AWSがサービスとして提供しているマスターを利用すれば、マスター管理が不要になります。ただ必要な設定は利用者が行う必要があるため、このあたりの効率的な展開方法をうまく見つけられれば運用工数が減らせると考えます。
2つ目、手元側のパソコンについてもOSが入っているため、ソフトウェアの管理やロックダウン機能による制約が現在発生しています。外部デバイスとの接続に制限があったり、WorkSpacesとの画面や音声・スピーカーなどの設定制御をうまく連動させる必要があります。セキュリティを担保しつつ、手元側の物理管理及び内部OSの管理をなくせると、さらに運用工数が減らせると考えます。
そして3つ目。今はだいぶ社内でも認知されてきましたが、手元側のOS画面とWorkSpacesのOSの画面の違いがわかりづらいため、データの移動やコピーが簡単にできない、画面の切り替えがうまくいかない、Web会議でマイク・スピーカーの設定がうまくできないといった問い合わせが当初は多くありました。
これらは手元側で制御している機能なのか、WorkSpaces側で制御しているのかといったところまで、ユーザー側では判断できないことによるものです。問い合わせを少なくする目的もありますが、地道な啓蒙活動がまだまだ必要であると認識しています。
実際にWorkSpacesを使ってみての感想
「実際にWorkSpacesを使ってみてどうですか」という声に対し、私たちが感じた「ここが良かったWorkSpaces」ということで、感想を述べたいと思います。
AWSはマネージドサービスのため、サーバー基盤の保守・監視をする必要がなく、そのぶん人的リソースをほかの業務に充てることができます。接続のしやすさも、セキュリティを担保しながらでもBYODの対応により、MacやWindowsのOS、iPadなど、OSやデバイスに関係なく動作させることができます。提供のスピードも、周辺環境も整っているため申請があればすぐ提供できます。スペック変更も10分ほどでできるため、「業務に応じてメモリを増やしたい」といった提供もすぐ行うことができます。
一時的に社内へのアクセスをして、会社譲渡による利用者・外部プロジェクトメンバー・派遣社員への提供もスムーズで、時間課金を利用して安価に提供することができます。グローバルでの展開においても専用の仕組みが必要なく、WorkSpacesの展開ができているため、グローバルでの利用も安心することができます。
このように、従来の提供方法と比べると、クラウドならでは恩恵を受けることができ、スピード感を持てるところが非常に良かった点として挙げられます。
最後に「AWSへの期待」ということで。私たちがAWSを利用し続けるのは、常に顧客中心の考えに立ち、私たちの声を聞いて具現化するプロセスを高く評価しているからです。この考えを忘れずに、常に良いサービスを提供してくれることを今後も期待したいと思います。
私たちが欲しいと思った機能をサービスチームで検討し、数ヶ月後にはロードマップとして計画され、その後サービスリリースがされるといった経験が何度もありました。ただ最近では充実しすぎて、新しいサービスを知らないままであったり、知っていても使いこなすのがやっと、という状況でもあります。
必ずしも当社の事例がみなさまにヒットするわけではないかと思いますが、本日ご紹介させていただいた内容が1つでもヒントになれば幸いです。
以上で本日のセッションを終了させていただきます。ありがとうございました。