├── 8.UseSSL └── README.md ├── 6.CheckSupportedApplicationPlatform └── README.md ├── 7.ThinkAboutAuthS └── README.md ├── 5.CannotInstall3rdControls └── README.md ├── 2.DonotUseWindowsAuthOnSQLServer └── README.md ├── 9.ScaleOutInsteadOfScaleUp └── README.md ├── README.md ├── 3.YouNeedAlternativeForWindowService └── README.md ├── 10.UTCTimezone └── README.md ├── 4.FileUpload └── README.md └── 1.DonotUseInProcSession └── README.md /8.UseSSL/README.md: -------------------------------------------------------------------------------- 1 | ##8. SSL을 제공해야 합니다 2 | 3 | 공식 인증서 제공업체로부터 발급받은 유효한 인증서를 사용하여 SSL을 제공해야 합니다. 모든 것이 온-프레미스 내부에 놓여있는 경우에는 굳이 SSL을 고려할 필요가 없었겠지만 공용 클라우드로 옮기게 되면 해킹의 위험이 높아지므로 더욱 신중하게 대비할 필요가 있습니다. 4 | 5 | ##해결방안 6 | 7 | Azure App 서비스에 SSL을 적용하는 방법은 다음 링크를 참고하시기 바랍니다. 다양한 유형의 인증서와 다양한 언어 별 사용 방안을 설명하고 있습니다. 8 | 9 | Azure 앱 서비스에서 앱에 대한 HTTPS를 사용하도록 설정 10 | https://azure.microsoft.com/ko-kr/documentation/articles/web-sites-configure-ssl-certificate/ 11 | -------------------------------------------------------------------------------- /6.CheckSupportedApplicationPlatform/README.md: -------------------------------------------------------------------------------- 1 | ##6. 응용프로그램에 맞게 지원되는 적절한 플랫폼을 선택해야 합니다 2 | 3 | 여러분의 기존 응용프로그램을 현재의 모습 그대로 Azure로 옮기려면 대부분 IaaS가 가장 효율적인 선택입니다. 그리고, 그 밖의 경우에는 Web App을 고려하는 것이 최선의 선택입니다. 이는 Azure PaaS인 Web App에서 지원하는 플랫폼에 제약이 있기 때문입니다. 예를 들면, 문서 집필 시점에 지원되는 웹 서버에는 IIS, Tomcat, Jetty 서버만이 있습니다. 또한, 기술 언어별(.NET, Java, Python, Php)로 지원하는 런타임 버전도 정해져 있으며 오래된 버전은 지원되지 않습니다. 그렇기에, 여러분의 웹 응용프로그램을 Web App에서 호스팅 하고자 한다면 그 기반 위에서 올바로 동작하는 지를 사전에 점검하고 필요하다면 그 플랫폼 상에서 동작하도록 코드를 변경해야 합니다. 4 | 5 | ## 해결방안 6 | 7 | 이 부분은 별도의 방안이 없으며 직접 상황에 맞게 선택 및 결정해야 합니다. 8 | -------------------------------------------------------------------------------- /7.ThinkAboutAuthS/README.md: -------------------------------------------------------------------------------- 1 | ##7. 인증과 권한 허가에 대해 고려해야 합니다 2 | 3 | 온-프레미스 웹 응용프로그램을 클라우드로 이전하는 경우에 간과하고 넘어가기 쉬운 부분 중 하나는 Windows 통합 인증입니다. 여러분의 응용프로그램에서 Windows 통합 인증을 사용하고 있었다면 이 부분은 클라우드로 이전할 경우 상당히 고전하게 되는 부분입다. 그렇기에 적절한 계획이 필요합니다. 4 | 5 | ##해결방안 6 | 7 | 직접적인 해법은 Azure Active Directory를 Directory Sync와 함께 사용하는 것입니다. 하지만 이 경우 OAuth, SAML 등을 사용해야 하기 때문에 코드 변경이 뒤따를 수 밖에 없습니다. 사실 마이그레이션을 할 경우 가장 큰 난관이 바로 이 부분입니다. ASP.NET 웹 응용프로그램에서 Azure Active Directory를 통해 인증하는 방법은 다음 링크를 살펴보시기 바랍니다. 8 | 9 | https://azure.microsoft.com/ko-kr/documentation/articles/web-sites-authentication-authorization/ 10 | 11 | -------------------------------------------------------------------------------- /5.CannotInstall3rdControls/README.md: -------------------------------------------------------------------------------- 1 | ## 5. 설치형 3rd 파티 컴포넌트는 사용할 수 없습니다 2 | 3 | 서버에 설치가 필요한 모든 서드파티 컴포넌트나 GAC(Global Assembly Cache)에 놓여야 하는 컴포넌트들은 문제가 될 수 있습니다. Azure PaaS는 웹 서버가 설치된 플랫폼 공간만을 대여하는 구조이기에 물리적인 가상 컴퓨터 (VM)에 소프트웨어를 설치하거나 그의 내부 공간에 접근할 수 있는 방법은 없습니다. 그렇기에, Install이 필요한 파일 업로드 컴포넌트나 SMS 발신 컴포넌트, 메일 및 FAX 발신 컴포넌트 등 서버에 인스톨이 필요한 모든 서드파티 컴포넌트는 사용할 수 없으며 대체 방안을 모색해야 합니다. 반드시 설치를 해야 할 수 밖에 없다면 PaaS가 아닌 IaaS를 도입하여 가상 컴퓨터(VM)을 직접 구성하고 그곳에 설치하여 사용해야 합니다. 4 | 5 | ## 해결방안 6 | 7 | 가장 좋은 방안은 설치용 서드파티 컴포넌트의 대체품을 찾는 것입니다. 해당 서드파티 업체가 Install 기반의 소프트웨어가 아닌 서비스 기반의 소프트웨어(SaaS)를 제공하는 지 확인해 보십시오. 요즘에는 Web API 기반으로 동작하는 서비스 기반의 소프트웨어들(사용한 만큼만 비용을 지불하는)도 많이 출시되고 있기에, 생각보다 쉽게 대체 컴포넌트를 찾으실 수도 있을 것입니다. 또한, Azure의 마켓 플레이스에도 다양한 서비스들이 존재하고 있으니 그 곳에서도 필요한 제품을 찾아볼 수 있습니다. 8 | 9 | 만일, 대체 방안을 구할 수 없어서 반드시 인스톨해야 한다면 IaaS로 바꾸는 것이 유일한 방법입니다. Azure PaaS 중 클라우드 서비스를 사용할 경우에는 일부 우회적인 방안이 존재하긴 합니다만 이는 권장되지 않습니다. 10 | -------------------------------------------------------------------------------- /2.DonotUseWindowsAuthOnSQLServer/README.md: -------------------------------------------------------------------------------- 1 | ##2. SQL 서버에서 Windows 인증을 사용하지 마십시오. 2 | 3 | SQL 서버와의 연결에 Windows 인증을 사용하는 것은 수많은 LOB(Line of Business, 업무용) 응용프로그램에서 상당히 보편적입니다. 접근 및 설정이 용이하기 때문입니다. 간혹, 어떤 이들은 백엔드 SQL 데이터베이스로의 접근을 제한하기 위해서 액티브 디렉토리(AD) 보안 그룹을 활용하기도 하는데, 이를 사용하면 데이터베이스로의 접근과 다양한 보안 수준을 정의하기 위해서 추가적으로 코딩을 해야 할 필요가 없기 때문입니다. 하지만, 여러분이 PaaS 기반으로 웹 응용프로그램을 이전하는 경우에는 이러한 방식이 항상 제대로 동작하지는 않을 수도 있습니다. 예를 들자면, SQL Azure 데이터베이스는 Windows 인증을 지원하지 않습니다. 4 | 5 | ##해결방안 6 | 7 | 가능하다면 SQL 인증을 사용하십시오. 만일, 여러분의 데이터베이스를 Azure SQL 데이터베이스로 이전한다면 사용 가능한 인증 방법은 SQL 인증 밖에 없기 때문입니다. Azure SQL 데이터베이스와 SQL Server (on-premises)의 차이점에 대해서는 다음의 공식 문서를 참고해 보시기 바랍니다. 8 | 9 | https://azure.microsoft.com/ko-kr/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/ 10 | 11 | 간혹, SQL Server는 온-프레미스에 존재하는 머신을 그대로 사용하지만 웹 응용프로그램은 Azure 상에서 운용하고 싶은 경우도 있는데 이 경우에는 설정이나 보안과 관련하여 다양한 제약이 발생할 수 있습니다. 이러한 경우의 대안으로는 WCF 서비스와 함께 “서비스 버스 릴레이”를 사용하는 방안을 고려할 수도 있습니다. 자세한 내용은 다음의 링크들을 참고하시기 바랍니다. 12 | 13 | >Azure 서비스 버스 릴레이 서비스를 사용하는 방법 14 | >https://azure.microsoft.com/ko-kr/documentation/articles/service-bus-dotnet-how-to-use-relay/ 15 | > 16 | >Connecting on-premises SQL Server using Azure Service Bus Relay 17 | >https://blogs.msdn.microsoft.com/wriju/2015/07/09/connecting-on-premises-sql-server-using-azure-service-bus-relay/ 18 | -------------------------------------------------------------------------------- /9.ScaleOutInsteadOfScaleUp/README.md: -------------------------------------------------------------------------------- 1 | ##9. Scale-up이 아닌 Scale-out을 고려하십시오 2 | 3 | 일반적으로 VM의 용량(크기)를 늘리는 방식(Scale-up)으로는 최적의 성능을 내기 어렵습니다. 이는 가동 중지 시간도 유발할 수 있으며 예상보다 만족할만한 성능을 즉각적으로 얻기도 쉽지 않습니다. 4 | 5 | ##해결방안 6 | 7 | 가능하다면 언제나 웹 응용프로그램의 인스턴스를 여러 개로 늘려서 분산처리하는 Scale-out 을 선택해야 합니다. IaaS에서는 이를 위해서는 2대 이상의 VM을 만들어서 가용성 집합을 구성하고 VM들의 앞 단에 부하분산 장치를 붙이는 형태의 설계가 필요합니다. 그리고 이러한 설계는 모든 클라우드 기반의 인프라에서 기본적인 권장 설계이기도 합니다. 더불어, PaaS에서는 이미 WebApp이 이를 위한 기반을 제공하므로 매우 쉽게(Azure Portal에서) 수평 확장 설정을 할 수 있습니다. 수동으로 확장할 수 있을 뿐만 아니라 CPU나 기타 메트릭의 수치 변화에 따라 자동으로 확장하는 Auto-Scale 기능도 사용할 수 있습니다. Azure 앱 서비스에 수평 확장을 적용하는 방법은 다음 문서를 참고하시기 바랍니다. 8 | 9 | Azure 앱 서비스에서 웹 앱 크기 조정 10 | https://azure.microsoft.com/ko-kr/documentation/articles/web-sites-scale/ 11 | 12 | 또한, 어느 정도의 규모로 Scale-out하는 것이 가장 효과적인지를 검증하기 위해서는 클라우드 기반의 부하 테스트도 고려하실 것을 권장합니다. Azure 기반의 Visual Studio Load Test는 이러한 규모 대응 계획을 수립할 때 큰 도움이 되는 부하 테스트 기법입니다. 참고로, 2015년에 슈퍼서울콘서트가 이와 같은 테스트를 거쳐서 성공적으로 사전 규모 진단을 수행하고 예매 대란을 해결한 사례가 있습니다. 13 | 14 | > 2015 슈퍼 서울 콘서트, MS 애저로 예매 대란 해결 15 | > 16 | >http://news.joins.com/article/19249462 17 | >http://www.datanet.co.kr/news/articleView.html?idxno=95277 18 | 19 | Visual Studio Load Test에 대한 상세한 설명은 다음 링크를 참고하시기 바랍니다. 20 | 21 | https://msdn.microsoft.com/library/vs/alm/test/performance-testing/getting-started/getting-started-with-performance-testing 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Azure PaaS 개발 시 주의해야 할 사항들 2 | 3 | 여러분의 웹 응용프로그램을 Azure의 PaaS 환경으로 이전할 계획을 가지고 있다거나, 혹은 새롭게 클라우드 기반의 Web App(웹 앱)을 제작할 계획을 가지고 있다면 다음의 다양한 조건들을 사전에 검토해 보시기 바랍니다. 4 | 5 | 기본적으로 웹 응용프로그램이 분산 환경을 지원하도록 설계되어 있다면 50% 이상은 이전할 준비가 되어 있는 것입니다만, 다른 계층(Layer)의 애플리케이션과의 연동을 위해서는 소스의 변경이나 아키텍처의 재설계가 요구될 수도 있습니다. 6 | 7 | 이 문서에서는 다양한 고려사항들을 하나씩 차례대로 살펴보도록 하겠습니다. 8 | 시작 전에 한 가지 언급하자면, 여러분의 웹 응용프로그램이 웹 팜(WebFarm) 환경을 지원하도록 설계되었다면 이하의 고려 사항 중 많은 부분은 이미 충족되어 있을 것이라는 점입니다. 그렇기에, 무엇보다 먼저 웹팜(여러 대의 웹 서버에 응용프로그램을 분산 배치하여 운영하는 설계)을 지원하도록 응용프로그램을 설계하시기 바랍니다. 9 | 10 | 1. [In-Proc 세션은 사용하지 마십시오](/1.DonotUseInProcSession/) 11 | 2. [SQL 서버에서 Windows 인증을 사용하지 마십시오](/2.DonotUseWindowsAuthOnSQLServer/) 12 | 3. [Windows 서비스를 사용하고 있었다면 대안을 찾아야 합니다](/3.YouNeedAlternativeForWindowService/) 13 | 4. [파일 업로드를 서버의 로컬 경로에 하면 안됩니다](/4.FileUpload/) 14 | 5. [설치형 3rd-party 컴포넌트는 사용할 수 없습니다](/5.CannotInstall3rdControls/) 15 | 6. [응용프로그램에 맞게 지원되는 적절한 플랫폼을 선택해야 합니다](/6.CheckSupportedApplicationPlatform/) 16 | 7. [인증과 권한 허가에 대해 고려해야 합니다](/7.ThinkAboutAuthS/) 17 | 8. [SSL을 제공해야 합니다](/8.UseSSL/) 18 | 9. [Scale-up이 아닌 Scale-out을 고려하십시오](/9.ScaleOutInsteadOfScaleUp/) 19 | 10. [서버의 UTC 시간을 고려하십시오](/10.UTCTimezone/) 20 | 11. 21 | 22 | 23 | > 참고 문서 24 | __Top 10 things while migrating existing Web Applications to Azure__ 25 | https://blogs.msdn.microsoft.com/wriju/2015/07/07/top-10-things-while-migrating-existing-web-applications-to-azure/ -------------------------------------------------------------------------------- /3.YouNeedAlternativeForWindowService/README.md: -------------------------------------------------------------------------------- 1 | ## 3. Windows 서비스를 사용하고 있었다면 대안을 찾아야 합니다. 2 | 3 | 웹 응용프로그램은 가끔 백엔드 작업들을 수행하기 위해서(예를 들면, 데이터베이스 관련 작업이나 시스템 마무리 작업 등) Windows 서비스를 사용합니다. 물론, IaaS 방식으로 가상 컴퓨터(VM)에서 응용프로그램을 호스트하는 경우에는 Windows 서비스를 사용할 수 있긴 하지만, 그 방식은 아주 깔끔한 방식이라 할 수 없으며, PaaS 환경에서는 Windows 서비스를 아예 사용할 수 없습니다. 4 | 5 | ##해결방안 6 | 7 | 첫번째 대안은 CQRS(Command Query Responsibility Segregation) 패턴과 함께 작업자 역할(Worker Role)을 사용하는 것입니다. CQRS 패턴에 대한 설명은 다음 링크를 참고하시기 바랍니다. 이는 조회 작업과 변경 작업을 분리하여 수행하는 패턴이며, 주로 클라우드 환경에 적합한 패턴이라 할 수 있습니다. 8 | 9 | > https://msdn.microsoft.com/en-us/library/azure/dn568103.aspx 10 | > http://blog.aliencube.org/ko/2013/08/18/cqrs-oversimplified-overview/ (한글, [유정협 MVP](https://twitter.com/justinchronicle) 작성) 11 | 12 | 다른 대안으로는 Web Jobs을 들 수 있습니다. 이는 웹 응용프로그램(Web App)에서 백그라운드 작업이 필요한 경우에 효과적인 방안이라 할 수 있습니다. 게다가, 다양한 실행 파일을 지원하기에 매우 유연합니다. 지원하는 파일 형식은 다음과 같습니다. 13 | .cmd, .bat, .exe(windows cmd 사용), .ps1(powershell 사용), .sh(bash 사용), .php(php 사용), .py(python 사용), .js(node 사용), .jar(java 사용) 14 | 다만, 이는 Web App과 동일한 가상 컴퓨터(VM)에서 작업이 수행되므로 대규모 프로세스를 수행하는 것은 효과적이지 않을 수 있습니다. Web Job에 대한 자세한 설명은 다음 링크를 참고하시기 바랍니다. 15 | 16 | > https://azure.microsoft.com/ko-kr/documentation/articles/web-sites-create-web-jobs/ 17 | > https://azure.microsoft.com/ko-kr/documentation/articles/websites-webjobs-resources/ 18 | 19 | 만일, 처리해야 할 작업이 대규모이고 더 많은 컴퓨팅 리소스가 필요하다면 Azure 배치(Batch)의 사용을 고려해 보시기 바랍니다. 20 | 21 | > Azure Batch .NET 자습서 22 | > https://azure.microsoft.com/ko-kr/documentation/articles/batch-dotnet-get-started/ 23 | -------------------------------------------------------------------------------- /10.UTCTimezone/README.md: -------------------------------------------------------------------------------- 1 | ##10. 서버의 UTC 시간을 고려하십시오 2 | 3 | Azure App Service의 모든 PaaS 응용프로그램은 서로 다른 지역(Region)의 서로 다른 데이터센터에서 운영된다 하더라도 동일한 시간대를 갖습니다. 즉, 지역에 무관하게 모두 세계 표준시(UTC)를 따른다는 것이며, 일본에 있는 데이터센터라고 해서 일본 시간대를 따르거나, 미국 동부에 있는 데이터센터라고 해서 미국 동부 시간대를 따르지 않는다는 것입니다. 그렇기에, 기존의 응용프로그램이 이러한 시간을 중요하게 다루고 있다면 접속한 최종 사용자의 지역에 따라 적절히 변환하여 보여주어야 합니다. 4 | 특히, SQL Azure를 사용할 경우에는 심도 있게 고려해야 합니다. SQL Azure도 마찬가지로 UTC가 기본 시간대이고 getdate() 시에 UTC 시간을 가져오게 됩니다. 문제는 대부분의 기존 응용프로그램들이 Local 시간을 데이터베이스에 기록해왔다는 것입니다. 그렇기에, Azure로 전환한 이후에는 기존 날짜 데이터와 UTC 날짜 데이터가 섞이게 될 수 있으면 식별이 어려워질 수 있습니다. 그렇기에, 날짜 데이터를 일관되게 다루기 위한 전략이 필요합니다. 5 | 6 | ##해결방안 7 | 8 | UI 측면에서는 웹 응용프로그램에서 다음과 같은 변환 코드(C#의 예)를 사용하여 시스템의 UTC 시간을 로컬 시간에 맞게 출력해 주도록 합니다. 9 | 10 | ```{cs} 11 | DateTime convertedDate = DateTime.SpecifyKind( 12 | DateTime.Parse(dateStr), 13 | DateTimeKind.Utc); 14 | DateTime dt = convertedDate.ToLocalTime(); 15 | ``` 16 | 17 | SQL Azure를 사용할 경우에는 기존의 Local 시간 데이터와 이제부터의 UTC 시간 데이터의 Time Zone을 맞추기 위한 정책이 필요합니다. 다음 중의 한 가지 방법을 선택하여 사용할 수 있습니다만, 이는 공식 권장사항은 아니며 커뮤니티에서 주로 거론되는 방식이기에 참고로 살펴보시기 바랍니다. 18 | 19 | 1. 기존에 로컬 시간으로 저장해 두었다면 그를 모두 UTC로 변경한다 20 | 2. TimeZone 관련 컬럼을 추가하여 기존 날짜 데이터(Local)와 신규 날짜 데이터(UTC)를 구분할 수 있도록 한다. 즉, 기존 날짜 데이터들에 대해서는 타임존 컬럼에 Local을 기록하고, 신규 시간 데이터들은 UTC를 기록한 뒤, 그에 따라 응용프로그램 서버에서 시간 데이터를 변환하여 사용하는 것이다. 21 | 3. UTC 기간을 로컬 시간에 맞게 변환하여 저장하여 사용한다. 22 | 23 | 어떠한 방식을 사용하던 여러분의 상황에 맞는 방안을 결정하여 사용하시기 바랍니다. 다음은 참고할만한 문서입니다. 24 | 25 | Manage TimeZone for Applications on Windows Azure 26 | https://blogs.msdn.microsoft.com/cie/2013/07/29/manage-timezone-for-applications-on-windows-azure/ 27 | 28 | Managing Timezone in SQL Azure 29 | http://wely-lau.net/2011/07/10/managing-timezone-in-sql-azure-2/ 30 | -------------------------------------------------------------------------------- /4.FileUpload/README.md: -------------------------------------------------------------------------------- 1 | ##4. 파일 업로드를 서버의 로컬 경로에 하면 안됩니다 2 | 3 | 대부분의 웹 응용프로그램은 파일 업로드 기능을 제공합니다. 즉, 이미지나 문서 파일을 서버로 업로드할 수 있는 기능을 제공하곤 합니다. 다만, 많은 웹 응용프로그램들이 업로드된 파일을 로컬 폴더(예, D:\Files 등)에 저장하는 방식을 취하는데, 이 방식은 클라우드의 PaaS와 같은 분산 환경에서는 문제가 발생할 수 있습니다. 즉, 웹 응용프로그램이 여러 대의 웹 서버에서 구동되는 경우에는 사용자가 업로드한 파일이 다른 서버에 존재하게 되는 문제가 생길 수 있기 때문입니다(이는 1번 세션 문제와 유사한 상황이라 할 수 있습니다). 그렇기에, 모든 파일들을 중앙 지점에서 관리할 수 있는 방안이 필요하며, 그에 따라 코드를 수정해야 할 수 있습니다. 4 | 5 | ##해결방안 6 | 7 | 가장 간편한 방안은 중앙 파일 저장소로 Azure Blob 저장소를 사용하는 것입니다. 이는 생각보다 사용하기에 매우 용이합니다. 저장소를 활용하는 예는 다음 문서들을 참고하시기 바랍니다. 다양한 프로그래밍 언어를 지원할 뿐만 아니라 사용하기도 용이합니다. 8 | 9 | > https://azure.microsoft.com/ko-kr/documentation/articles/storage-dotnet-how-to-use-blobs/ 10 | > https://azure.microsoft.com/ko-kr/documentation/articles/storage-java-how-to-use-blob-storage/ 11 | 12 | 13 | 추가적으로, 참고할 만한 예제로써 웹 응용프로그램에서 Azure Blob으로 파일을 저장하고 불러오는 예제(HTML Form 버전과 Javascript Ajax 버전)를 만들어 보았습니다. 관련 샘플이 필요하신 분은 다음 링크의 예제를 확인해 보시기 바랍니다. 14 | 15 | __Azure 파일 업로드__ 16 | https://github.com/jiyongseong/AzurePaaSHol/tree/master/AzureFileUploadWeb 17 | 18 | 다음은 예제의 간단한 설명입니다. 19 | 20 | - 기본 예제는 ASP.NET MVC 기본 파일 업로드 방식으로 작성됨 21 | - ASP.NET MVC에서 그리드는 Grid.MVC를 활용 22 | - 추가 예제는 jQuery.Form을 활용한 HTML/Javascript 파일 업로드 방식으로 작성 23 | - 그리드는 Knockout을 활용하여 MVVM 으로 구현(Json 바인딩) 24 | - 서버 측은 Java나 Php 등으로 구현해도 무방함(예에서는 서버로 ASP.NET을 활용함) 25 | - 웹 페이지 혹은 스크립트를 통해서 업로드 되는 파일은 스트림 그대로 Azure Storage로 전송되도록 구현 26 | - 예제 소스는 이해하기 쉽도록 동기(Sync) 메서드를 사용하여 구현하였음 27 | 28 | 구현 시에 고려한 사항은 다음과 같습니다. 29 | 30 | - 모든 파일은 Azure Blob Storage의 특정 컨테이너에 저장한다. 31 | - Azure Blob Storage의 특정 컨테이너는 읽기 전용으로 설정해야 한다. 32 | - 사용자가 웹 서버로 업로드하는 파일은 스트림 그대로 Azure Storage 쪽에 저장해야 한다. 33 | - 사용자가 파일 내역을 조회하고자 하는 경우에는 웹 서버는 파일 목록과 해당 파일로의 직접적인 하이퍼링크를 제공한다 34 | - 웹 서버가 파일 다운로드를 중계하는 방식은 권장하지 않는다(메모리 낭비 및 CDN 적용 불가) 35 | - 사용자는 개별 파일에 대해서는 Azure Blob에 직접 접근하여 다운로드를 수행한다. 36 | -------------------------------------------------------------------------------- /1.DonotUseInProcSession/README.md: -------------------------------------------------------------------------------- 1 | ##1. In-Proc 세션은 사용하지 마십시오. 2 | 세션(Session)은 웹 개발에서는 매우 일반적으로 사용되는 개념입니다. 일반적으로 세션은 로컬 웹 서버에서 처리하도록 프로그래밍 되는 편이고 서버의 외부에서는 접근할 수 없습니다. 하지만, 분산 환경에서는 서로 다른 여러 대의 웹 서버에 응용프로그램을 배포하고 앞 단에 부하 분산기를 배치하여, 사용자의 요청을 분산 처리하게 구성하곤 합니다. 이러한 설계에서는 특정 웹 서버가 다운되거나 장애가 발생한다 하더라도 부하 분산기가 알아서 가용한 다른 웹 서버를 파악하여 그를 통해 요청을 처리해주는 가용성을 확보할 수 있게 됩니다. 하지만, 이러한 분산 설계 하에서는 세션과 관련하여 문제가 발생할 가능성이 있는데, 예를 들면 사용자가 처음에는 A 머신에 접속하여 로그인을 수행하여 세션을 맺었지만, 그 다음 요청은 B 머신으로 접속하게 될 수 있으며 이 경우 세션이 없는 것처럼 인식되어 다시 로그인을 수행해야 할 수 있습니다. 그렇기에, 분산 환경에서는 세션을 웹 서버에서 직접 관리(즉, In-Proc)하는 것이 아니라 별도로 관리하는 방안(예, 세션 서버)이 필요합니다. 3 | 4 | ##해결방안 5 | 일반적으로 세션의 상태(Session State)를 저장하기 위해서 파일 서버, 데이터베이스 서버, 캐시 서버 등이 활용되곤 합니다. 즉, 상태를 관리하는 별도의 서버를 두고 모든 세션은 그 서버를 통해서 관리하도록 한다는 것입니다. 이렇게 구성하면 웹 서버가 여러 대로 구성되는 웹팜(WebFarm) 환경에서도 매끄럽게 세션을 관리할 수 있습니다. 6 | Azure 에서는 상태 서버로 활용할 수 있는, 관리되는 캐시 서비스인 Redis Cache를 제공하고 있습니다. 물론 원한다면, 별도의 파일 서버나 RDBMS를 상태 서버로 활용할 수 있지만 최근의 추세는 기업 수준의 응용프로그램에서는 Redis Cache를 사용하는 것이 권장됩니다. 7 | ASP.NET 웹 응용프로그램의 경우는 기본적으로 .NET 프레임워크에서 Session State Provider가 제공되기에 다음과 같은 방안을 사용하여 매우 쉽게 Redis Cache 상태 서버를 구성할 수 있습니다. 8 | 9 | > Azure Redis Cache에 대한 ASP.NET 세션 상태 제공자 10 | > [https://azure.microsoft.com/ko-kr/documentation/articles/cache-asp.net-session-state-provider/](https://azure.microsoft.com/ko-kr/documentation/articles/cache-asp.net-session-state-provider/) 11 | 12 | > Azure 앱 서비스에서 Azure Redis 캐시를 사용하는 세션 상태 13 | > [https://azure.microsoft.com/ko-kr/documentation/articles/web-sites-dotnet-session-state-caching/](https://azure.microsoft.com/ko-kr/documentation/articles/web-sites-dotnet-session-state-caching/) 14 | 15 | 다만, Java 웹 응용프로그램의 경우에는 별도의 Session State Provider가 존재하지 않기에 오픈소스에서 지원되는 기술들을 검토해 보아야 합니다. Tomcat 서버를 사용하는 경우에는 Memcached Session Manager라는 모듈을 사용하여 고가용성을 확보할 수 있습니다. Memcached Session Manager는 memcached 기술을 사용한 고가용성 클러스터입니다. 이를 사용하여 상태를 관리하는 방안은 다음 링크들을 참고하시기 바랍니다. 16 | 17 | > https://code.google.com/archive/p/memcached-session-manager/ 18 | > https://github.com/magro/memcached-session-manager 19 | 20 | 반드시 이러한 기술을 사용해야만 하는 것은 아닙니다. 이미 여러분의 온-프레미스에서 상태 서버를 관리 및 운용하고 있다면 그를 Azure에 가상 컴퓨터(VM)으로 구성하여 여전히 활용할 수 있습니다. 21 | --------------------------------------------------------------------------------